From ed70cce6381e9fc321b98dbd6dcd63e4533fa841 Mon Sep 17 00:00:00 2001 From: GitHub Workshop Bot Date: Tue, 12 May 2026 19:20:26 -0700 Subject: [PATCH 1/6] feat(podcasts): add chapter-planned transcript workflow --- package.json | 5 + podcasts/README.md | 47 +- podcasts/chapters/ep00-welcome.json | 98 + podcasts/generate-draft-transcripts.js | 373 +- .../cc-02-file-your-first-issue.packet.json | 418 + .../agentic-pilots/chapter-plan-audit.json | 9294 +++++++++++++++++ ...ep05-working-with-issues-gpt54.report.json | 1069 ++ .../ep05-working-with-issues-gpt54.txt | 303 + .../ep05-working-with-issues.packet.json | 391 + .../ep20-accessibility-standards.packet.json | 135 + podcasts/tag-audio-metadata.py | 66 +- podcasts/tools/agentic-pilot/README.md | 93 + .../agentic-pilot/audit-chapter-plans.js | 95 + .../agentic-pilot/build-source-packet.js | 142 + .../agentic-pilot/evaluate-transcript.js | 221 + .../agentic-pilot/normalize-chapter-plans.js | 63 + podcasts/tools/agentic-pilot/promote-pilot.js | 130 + .../appendices/ep18-glossary-chapters.json | 34 + ...p19-screen-reader-cheatsheet-chapters.json | 54 + ...ep20-accessibility-standards-chapters.json | 46 + .../ep21-git-authentication-chapters.json | 50 + ...p22-github-flavored-markdown-chapters.json | 146 + .../ep23-github-gists-chapters.json | 94 + .../ep24-github-discussions-chapters.json | 94 + .../ep25-releases-tags-insights-chapters.json | 86 + .../ep26-github-projects-chapters.json | 50 + .../ep27-advanced-search-chapters.json | 38 + .../ep28-branch-protection-chapters.json | 50 + .../ep29-security-features-chapters.json | 50 + ...code-accessibility-reference-chapters.json | 42 + .../ep31-github-codespaces-chapters.json | 34 + .../ep32-github-mobile-chapters.json | 38 + .../ep33-github-pages-chapters.json | 46 + .../ep34-github-actions-chapters.json | 58 + .../ep35-profile-sponsors-wikis-chapters.json | 58 + ...ep36-organizations-templates-chapters.json | 58 + ...-contributing-to-open-source-chapters.json | 110 + .../appendices/ep38-resources-chapters.json | 66 + ...cessibility-agents-reference-chapters.json | 66 + .../ep40-copilot-reference-chapters.json | 102 + .../ep41-copilot-models-chapters.json | 102 + ...accessing-workshop-materials-chapters.json | 38 + .../ep43-github-skills-catalog-chapters.json | 34 + ...ep50-advanced-git-operations-chapters.json | 62 + ...it-security-for-contributors-chapters.json | 46 + .../ep52-github-desktop-chapters.json | 62 + .../ep53-github-cli-reference-chapters.json | 50 + .../cc-01-find-your-way-around-chapters.json | 190 + .../cc-02-file-your-first-issue-chapters.json | 70 + .../cc-03-join-the-conversation-chapters.json | 162 + .../challenges/cc-04-branch-out-chapters.json | 150 + .../cc-05-make-your-mark-chapters.json | 134 + .../cc-06-open-your-first-pr-chapters.json | 90 + ...-07-survive-a-merge-conflict-chapters.json | 78 + .../cc-08-open-source-culture-chapters.json | 154 + .../challenges/cc-09-merge-day-chapters.json | 142 + .../challenges/cc-10-go-local-chapters.json | 134 + .../cc-11-day-2-pull-request-chapters.json | 158 + .../cc-12-code-review-chapters.json | 194 + ...c-13-copilot-as-collaborator-chapters.json | 90 + ...-14-design-an-issue-template-chapters.json | 66 + ...iscover-accessibility-agents-chapters.json | 122 + .../cc-16-build-your-own-agent-chapters.json | 102 + .../cc-bonus-a-improve-agent-chapters.json | 102 + ...onus-b-document-your-journey-chapters.json | 250 + .../cc-bonus-c-group-challenge-chapters.json | 194 + .../cc-bonus-d-notifications-chapters.json | 78 + .../cc-bonus-e-git-history-chapters.json | 114 + .../chapters/ep00-welcome-chapters.json | 98 + .../ep01-pre-workshop-setup-chapters.json | 54 + .../ep02-github-web-structure-chapters.json | 62 + ...ep03-navigating-repositories-chapters.json | 82 + .../ep04-the-learning-room-chapters.json | 62 + .../ep05-working-with-issues-chapters.json | 50 + ...6-working-with-pull-requests-chapters.json | 74 + .../ep07-merge-conflicts-chapters.json | 58 + .../ep08-culture-and-etiquette-chapters.json | 110 + ...9-labels-milestones-projects-chapters.json | 38 + .../chapters/ep10-notifications-chapters.json | 62 + .../chapters/ep11-vscode-basics-chapters.json | 62 + .../ep12-git-source-control-chapters.json | 74 + .../ep13-github-prs-extension-chapters.json | 90 + .../ep14-github-copilot-chapters.json | 70 + .../ep15-accessible-code-review-chapters.json | 90 + .../ep16-issue-templates-chapters.json | 54 + .../ep17-accessibility-agents-chapters.json | 58 + .../ep44-choose-your-tools-chapters.json | 54 + ...code-accessibility-deep-dive-chapters.json | 46 + .../chapters/ep46-how-git-works-chapters.json | 54 + .../ep47-fork-and-contribute-chapters.json | 62 + ...48-build-your-agent-capstone-chapters.json | 46 + .../chapters/ep49-next-steps-chapters.json | 42 + 92 files changed, 19076 insertions(+), 57 deletions(-) create mode 100644 podcasts/chapters/ep00-welcome.json create mode 100644 podcasts/logs/agentic-pilots/cc-02-file-your-first-issue.packet.json create mode 100644 podcasts/logs/agentic-pilots/chapter-plan-audit.json create mode 100644 podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.report.json create mode 100644 podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.txt create mode 100644 podcasts/logs/agentic-pilots/ep05-working-with-issues.packet.json create mode 100644 podcasts/logs/agentic-pilots/ep20-accessibility-standards.packet.json create mode 100644 podcasts/tools/agentic-pilot/README.md create mode 100644 podcasts/tools/agentic-pilot/audit-chapter-plans.js create mode 100644 podcasts/tools/agentic-pilot/build-source-packet.js create mode 100644 podcasts/tools/agentic-pilot/evaluate-transcript.js create mode 100644 podcasts/tools/agentic-pilot/normalize-chapter-plans.js create mode 100644 podcasts/tools/agentic-pilot/promote-pilot.js create mode 100644 podcasts/transcripts/appendices/ep18-glossary-chapters.json create mode 100644 podcasts/transcripts/appendices/ep19-screen-reader-cheatsheet-chapters.json create mode 100644 podcasts/transcripts/appendices/ep20-accessibility-standards-chapters.json create mode 100644 podcasts/transcripts/appendices/ep21-git-authentication-chapters.json create mode 100644 podcasts/transcripts/appendices/ep22-github-flavored-markdown-chapters.json create mode 100644 podcasts/transcripts/appendices/ep23-github-gists-chapters.json create mode 100644 podcasts/transcripts/appendices/ep24-github-discussions-chapters.json create mode 100644 podcasts/transcripts/appendices/ep25-releases-tags-insights-chapters.json create mode 100644 podcasts/transcripts/appendices/ep26-github-projects-chapters.json create mode 100644 podcasts/transcripts/appendices/ep27-advanced-search-chapters.json create mode 100644 podcasts/transcripts/appendices/ep28-branch-protection-chapters.json create mode 100644 podcasts/transcripts/appendices/ep29-security-features-chapters.json create mode 100644 podcasts/transcripts/appendices/ep30-vscode-accessibility-reference-chapters.json create mode 100644 podcasts/transcripts/appendices/ep31-github-codespaces-chapters.json create mode 100644 podcasts/transcripts/appendices/ep32-github-mobile-chapters.json create mode 100644 podcasts/transcripts/appendices/ep33-github-pages-chapters.json create mode 100644 podcasts/transcripts/appendices/ep34-github-actions-chapters.json create mode 100644 podcasts/transcripts/appendices/ep35-profile-sponsors-wikis-chapters.json create mode 100644 podcasts/transcripts/appendices/ep36-organizations-templates-chapters.json create mode 100644 podcasts/transcripts/appendices/ep37-contributing-to-open-source-chapters.json create mode 100644 podcasts/transcripts/appendices/ep38-resources-chapters.json create mode 100644 podcasts/transcripts/appendices/ep39-accessibility-agents-reference-chapters.json create mode 100644 podcasts/transcripts/appendices/ep40-copilot-reference-chapters.json create mode 100644 podcasts/transcripts/appendices/ep41-copilot-models-chapters.json create mode 100644 podcasts/transcripts/appendices/ep42-accessing-workshop-materials-chapters.json create mode 100644 podcasts/transcripts/appendices/ep43-github-skills-catalog-chapters.json create mode 100644 podcasts/transcripts/appendices/ep50-advanced-git-operations-chapters.json create mode 100644 podcasts/transcripts/appendices/ep51-git-security-for-contributors-chapters.json create mode 100644 podcasts/transcripts/appendices/ep52-github-desktop-chapters.json create mode 100644 podcasts/transcripts/appendices/ep53-github-cli-reference-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-01-find-your-way-around-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-02-file-your-first-issue-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-03-join-the-conversation-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-04-branch-out-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-05-make-your-mark-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-06-open-your-first-pr-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-07-survive-a-merge-conflict-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-08-open-source-culture-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-09-merge-day-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-10-go-local-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-11-day-2-pull-request-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-12-code-review-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-13-copilot-as-collaborator-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-14-design-an-issue-template-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-15-discover-accessibility-agents-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-16-build-your-own-agent-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-bonus-a-improve-agent-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-bonus-b-document-your-journey-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-bonus-c-group-challenge-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-bonus-d-notifications-chapters.json create mode 100644 podcasts/transcripts/challenges/cc-bonus-e-git-history-chapters.json create mode 100644 podcasts/transcripts/chapters/ep00-welcome-chapters.json create mode 100644 podcasts/transcripts/chapters/ep01-pre-workshop-setup-chapters.json create mode 100644 podcasts/transcripts/chapters/ep02-github-web-structure-chapters.json create mode 100644 podcasts/transcripts/chapters/ep03-navigating-repositories-chapters.json create mode 100644 podcasts/transcripts/chapters/ep04-the-learning-room-chapters.json create mode 100644 podcasts/transcripts/chapters/ep05-working-with-issues-chapters.json create mode 100644 podcasts/transcripts/chapters/ep06-working-with-pull-requests-chapters.json create mode 100644 podcasts/transcripts/chapters/ep07-merge-conflicts-chapters.json create mode 100644 podcasts/transcripts/chapters/ep08-culture-and-etiquette-chapters.json create mode 100644 podcasts/transcripts/chapters/ep09-labels-milestones-projects-chapters.json create mode 100644 podcasts/transcripts/chapters/ep10-notifications-chapters.json create mode 100644 podcasts/transcripts/chapters/ep11-vscode-basics-chapters.json create mode 100644 podcasts/transcripts/chapters/ep12-git-source-control-chapters.json create mode 100644 podcasts/transcripts/chapters/ep13-github-prs-extension-chapters.json create mode 100644 podcasts/transcripts/chapters/ep14-github-copilot-chapters.json create mode 100644 podcasts/transcripts/chapters/ep15-accessible-code-review-chapters.json create mode 100644 podcasts/transcripts/chapters/ep16-issue-templates-chapters.json create mode 100644 podcasts/transcripts/chapters/ep17-accessibility-agents-chapters.json create mode 100644 podcasts/transcripts/chapters/ep44-choose-your-tools-chapters.json create mode 100644 podcasts/transcripts/chapters/ep45-vscode-accessibility-deep-dive-chapters.json create mode 100644 podcasts/transcripts/chapters/ep46-how-git-works-chapters.json create mode 100644 podcasts/transcripts/chapters/ep47-fork-and-contribute-chapters.json create mode 100644 podcasts/transcripts/chapters/ep48-build-your-agent-capstone-chapters.json create mode 100644 podcasts/transcripts/chapters/ep49-next-steps-chapters.json diff --git a/package.json b/package.json index f775e73..af9cb58 100644 --- a/package.json +++ b/package.json @@ -9,7 +9,12 @@ "build:podcast-bundles": "node podcasts/build-bundles.js", "build:podcast-challenge-bundles": "node podcasts/build-challenge-bundles.js", "generate:podcast-transcripts": "node podcasts/generate-draft-transcripts.js", + "generate:podcast-transcript": "node podcasts/generate-draft-transcripts.js", "build:podcast-transcripts": "npm run validate:podcasts && npm run build:podcast-bundles && npm run build:podcast-challenge-bundles && npm run generate:podcast-transcripts && npm run build:podcast-site", + "podcast:agentic:packet": "node podcasts/tools/agentic-pilot/build-source-packet.js", + "podcast:agentic:promote": "node podcasts/tools/agentic-pilot/promote-pilot.js", + "podcast:chapters:audit": "node podcasts/tools/agentic-pilot/audit-chapter-plans.js", + "podcast:chapters:normalize": "node podcasts/tools/agentic-pilot/normalize-chapter-plans.js", "build:podcast-audio": "python -m podcasts.tts.generate_audio --audio-format mp3", "build:podcast-audio:chapters": "python -m podcasts.tts.generate_audio --group chapters --audio-format mp3", "build:podcast-audio:challenges": "python -m podcasts.tts.generate_audio --group challenges --audio-format mp3", diff --git a/podcasts/README.md b/podcasts/README.md index 1114d44..edfe4f6 100644 --- a/podcasts/README.md +++ b/podcasts/README.md @@ -14,6 +14,9 @@ build-bundles.js Generate source bundles from chapter content scripts/*.txt Conversational scripts with [ALEX]/[JAMIE]/[PAUSE] markers | v + transcripts/*-chapters.json Ordered chapter plans by segment index + | + v tts/ Local neural TTS (ONNX models, pronunciation lexicon) | v @@ -64,9 +67,11 @@ podcasts/ bundles/ Generated companion prompt packets challenge-bundles/ Generated Challenge Coach prompt packets scripts/ Committed transcript source scripts - transcripts/ Derived segment JSON transcripts + transcripts/ Derived segment JSON transcripts and chapter plans + chapters/ Podcasting 2.0 chapter JSON sidecars written during metadata tagging audio/ Local audio output and segment cache, not committed logs/ Local generation and inventory reports + tools/agentic-pilot/ One-episode packet builder and transcript evaluation helpers tools/legacy/ Older diagnostic and one-off helpers tts/ Production and fallback TTS package ``` @@ -110,6 +115,22 @@ npm run generate:podcast-transcripts `podcasts/bundles/*.md` files are generated prompt packets. They are intentionally ignored by git and should be regenerated when needed. `podcasts/challenge-bundles/*.md` files are the same kind of generated prompt packet, but scoped to individual Challenge Coach episodes. +Transcript generation now writes three artifacts for each episode or challenge: + +- the transcript source in `podcasts/scripts/` +- the segment manifest in `podcasts/transcripts/*-segments.json` +- the ordered chapter plan in `podcasts/transcripts/*-chapters.json` + +The chapter plan is sequential, not time-based. It stores chapter titles with segment indexes. Later, the metadata pass converts those ordered boundaries into timed ID3 chapter markers and Podcasting 2.0 chapter sidecars after audio generation. + +You can also regenerate a subset instead of rebuilding all 75 scripts: + +```bash +npm run generate:podcast-transcript -- --slug ep05-working-with-issues +npm run generate:podcast-transcript -- --start 1 --end 4 --group challenges +npm run generate:podcast-transcript -- --start 20 --end 25 --group appendices +``` + ### 4. Generate all episodes Preview the listening-order generation queue without loading models or creating audio: @@ -203,6 +224,11 @@ The following table lists the supported podcast build and validation commands. | `npm run build:podcast-bundles` | Generate source bundles from chapters | | `npm run build:podcast-challenge-bundles` | Generate source bundles for Challenge Coach episodes | | `npm run generate:podcast-transcripts` | Replace old scripts with fresh reviewable Alex/Jamie draft transcripts | +| `npm run generate:podcast-transcript -- --slug ` | Regenerate one selected transcript or a filtered range using `--start`, `--end`, and `--group` | +| `npm run podcast:agentic:packet -- --slug ` | Build a single episode source packet for GPT-5.4 rewrite and review workflows | +| `npm run podcast:agentic:promote -- --slug ` | Promote an accepted GPT-5.4 pilot transcript into the live script path and refresh its segment JSON | +| `npm run podcast:chapters:normalize` | Normalize generated chapter-plan sidecars to remove weak or overly generic titles | +| `npm run podcast:chapters:audit` | Audit all generated chapter-plan sidecars and report title quality across the full catalog | | `npm run build:podcast-transcripts` | Run validation, regenerate bundles, regenerate transcripts, and rebuild podcast page/feed | | `npm run build:podcast-audio` | Generate MP3 audio for all companion, Challenge Coach, and bonus scripts with local Kokoro TTS | | `npm run build:podcast-audio:piper` | Generate audio with the legacy local Piper TTS path | @@ -254,10 +280,25 @@ The metadata tool writes the following ID3 fields to each MP3: - Author website: [Community Access website](http://www.community-access.org) - Description: episode description or challenge focus - Episode script: the matching `podcasts/scripts/*.txt` source embedded as both a custom text frame and an unsynchronized lyrics frame -- Smart chapters: ID3 chapter frames derived from `podcasts/audio/segments//manifest.json` +- Smart chapters: ID3 chapter frames derived from `podcasts/audio/segments//manifest.json`, preferring transcript-authored chapter plans from `podcasts/transcripts/*-chapters.json` when available - Chapter sidecars: Podcasting 2.0 JSON files in `podcasts/chapters/`, linked from RSS as `podcast:chapters` -Chapter markers are pause-aware. The tool starts with the opening segment, prefers natural boundaries after `[PAUSE]`, avoids very short chapters, and forces a new marker when a section grows too long. Chapter titles are generated from the next spoken segment with small heuristics for questions, "big idea" openings, practice anchors, and why-it-matters sections. +Chapter markers now have a two-stage flow: + +1. Transcript generation writes ordered chapter plans using segment indexes, while the lesson structure is still available. +2. Metadata tagging converts those segment indexes into timed chapter markers after audio generation. + +If no transcript-authored chapter plan exists, the metadata tool falls back to the older pause-aware heuristic. That fallback starts with the opening segment, prefers natural boundaries after `[PAUSE]`, avoids very short chapters, and forces a new marker when a section grows too long. + +For one-episode GPT-5.4 pilot work, see `podcasts/tools/agentic-pilot/README.md`. + +For a full-catalog refresh, the recommended sequence is: + +```bash +npm run generate:podcast-transcripts +npm run podcast:chapters:normalize +npm run podcast:chapters:audit +``` Run the dry-run check first: diff --git a/podcasts/chapters/ep00-welcome.json b/podcasts/chapters/ep00-welcome.json new file mode 100644 index 0000000..5cb1250 --- /dev/null +++ b/podcasts/chapters/ep00-welcome.json @@ -0,0 +1,98 @@ +{ + "version": "1.2.0", + "title": "Episode 0: Welcome to Git Going with GitHub", + "chapters": [ + { + "startTime": 0, + "title": "Welcome to Git Going with GitHub: Overview" + }, + { + "startTime": 45, + "title": "GitHub Learning Room - Your Complete Workshop Companion" + }, + { + "startTime": 68, + "title": "How This Course Works" + }, + { + "startTime": 215, + "title": "Before You Begin" + }, + { + "startTime": 242, + "title": "Companion Audio Series" + }, + { + "startTime": 287, + "title": "Day 1: GitHub Foundations" + }, + { + "startTime": 312, + "title": "Day 2: VS Code + Accessibility Agents" + }, + { + "startTime": 314, + "title": "Appendices - Reference Material" + }, + { + "startTime": 333, + "title": "Exercises at a Glance" + }, + { + "startTime": 360, + "title": "Getting Help" + }, + { + "startTime": 386, + "title": "Workshop at a Glance" + }, + { + "startTime": 390, + "title": "What This Guide Does" + }, + { + "startTime": 434, + "title": "When Tools or Pages Change" + }, + { + "startTime": 484, + "title": "Step 1 - Know Your Starting Place" + }, + { + "startTime": 499, + "title": "Step 2 - Accept the GitHub Classroom Assignment" + }, + { + "startTime": 591, + "title": "Step 3 - Understand the Learning Room" + }, + { + "startTime": 609, + "title": "Step 4 - Find Challenge 1" + }, + { + "startTime": 665, + "title": "Step 5 - Choose the Tool That Fits the Moment" + }, + { + "startTime": 720, + "title": "Step 6 - What to Listen For with a Screen Reader" + }, + { + "startTime": 739, + "title": "Step 7 - Use the Support Built into the Course" + }, + { + "startTime": 794, + "title": "Step 8 - Your First Success Check" + }, + { + "startTime": 818, + "title": "Where to Go Next" + }, + { + "startTime": 868, + "title": "Welcome to Git Going with GitHub: Wrap-Up" + } + ] +} diff --git a/podcasts/generate-draft-transcripts.js b/podcasts/generate-draft-transcripts.js index e47e8d1..4b690a8 100644 --- a/podcasts/generate-draft-transcripts.js +++ b/podcasts/generate-draft-transcripts.js @@ -22,6 +22,93 @@ const SCRIPTS_DIR = path.join(__dirname, 'scripts'); const TRANSCRIPTS_DIR = path.join(__dirname, 'transcripts'); const SCRIPT_GROUP_DIRS = ['chapters', 'challenges', 'appendices']; +function parseArgs(argv) { + const args = { + slug: null, + start: null, + end: null, + group: 'all' + }; + + for (let index = 0; index < argv.length; index += 1) { + const token = argv[index]; + const value = argv[index + 1] && !argv[index + 1].startsWith('--') ? argv[++index] : null; + if (token === '--slug' && value) args.slug = value; + else if (token === '--start' && value) args.start = Number.parseInt(value, 10); + else if (token === '--end' && value) args.end = Number.parseInt(value, 10); + else if (token === '--group' && value) args.group = value; + } + + return args; +} + +function shouldIncludeRange(number, args) { + if (typeof number !== 'number') return true; + if (Number.isInteger(args.start) && number < args.start) return false; + if (Number.isInteger(args.end) && number > args.end) return false; + return true; +} + +function selectedScriptGroups(args) { + if (args.group === 'all') return new Set(SCRIPT_GROUP_DIRS); + return new Set([args.group]); +} + +function shouldGenerateCompanion(episode, args) { + const group = scriptGroupForCompanion(episode); + if (!selectedScriptGroups(args).has(group)) return false; + if (args.slug) { + const episodeSlug = `ep${String(episode.number).padStart(2, '0')}-${episode.slug}`; + return args.slug === episodeSlug; + } + return shouldIncludeRange(episode.number, args); +} + +function shouldGenerateChallenge(challenge, args) { + if (!selectedScriptGroups(args).has('challenges')) return false; + const challengeSlug = `cc-${challenge.id}-${challenge.slug}`; + if (args.slug) return args.slug === challengeSlug; + const numericId = Number.parseInt(challenge.id, 10); + if (Number.isNaN(numericId)) return args.start == null && args.end == null; + return shouldIncludeRange(numericId, args); +} + +function removeScriptArtifacts(baseDir, fileName) { + let removed = 0; + for (const entry of SCRIPT_GROUP_DIRS) { + const target = path.join(baseDir, entry, fileName); + if (fs.existsSync(target)) { + fs.unlinkSync(target); + removed += 1; + } + } + const directTarget = path.join(baseDir, fileName); + if (fs.existsSync(directTarget)) { + fs.unlinkSync(directTarget); + removed += 1; + } + return removed; +} + +function removeSelectedOutputs(selectedFiles) { + let removedScripts = 0; + let removedSegments = 0; + let removedChapters = 0; + for (const fileName of selectedFiles) { + removedScripts += removeScriptArtifacts(SCRIPTS_DIR, fileName); + removedSegments += removeScriptArtifacts(TRANSCRIPTS_DIR, fileName.replace(/\.txt$/, '-segments.json')); + removedChapters += removeScriptArtifacts(TRANSCRIPTS_DIR, fileName.replace(/\.txt$/, '-chapters.json')); + } + return { removedScripts, removedSegments, removedChapters }; +} + +function trimChapterTitle(text, maxLength = 64) { + const normalized = cleanText(text).replace(/^[:\-\s]+/, '').trim(); + if (normalized.length <= maxLength) return normalized; + const boundary = normalized.lastIndexOf(' ', maxLength - 1); + return `${normalized.slice(0, boundary > 24 ? boundary : maxLength - 1).trim()}...`; +} + function ensureDir(dir) { fs.mkdirSync(dir, { recursive: true }); } @@ -103,6 +190,138 @@ function pause() { return '[PAUSE]\n'; } +function createScriptBuilder() { + return { + lines: [], + segmentCount: 0, + chapters: [] + }; +} + +function addSpokenLine(builder, speaker, text) { + builder.lines.push(marker(speaker, text)); + builder.segmentCount += 1; +} + +function addPauseLine(builder) { + builder.lines.push(pause()); + builder.segmentCount += 1; +} + +function addChapterCue(builder, title) { + const cleaned = trimChapterTitle(title || ''); + if (!cleaned) return; + const previous = builder.chapters[builder.chapters.length - 1]; + if (previous && previous.segmentIndex === builder.segmentCount) { + previous.title = cleaned; + return; + } + builder.chapters.push({ title: cleaned, segmentIndex: builder.segmentCount }); +} + +function normalizeChapterPlan(chapters) { + const blockedTitles = /^(learning cards?:|step-by-step$|on the issues list page$|on an open issue$|title field$|description \/ body field$|quick navigation$|useful filter queries$|what happened$|what i expected$|how to reproduce$|environment$|assigning labels from the sidebar$)/i; + const genericTitles = /^(challenge roadmap|what success looks like|recovery moves|the learning pattern|cli alternative|search and filter issues|link issues together|write better issues|file your first issue)$/i; + const normalized = []; + + for (const chapter of chapters) { + const title = trimChapterTitle(chapter.title || ''); + if (!title || blockedTitles.test(title)) continue; + if (genericTitles.test(title)) continue; + const previous = normalized[normalized.length - 1]; + if (previous && previous.title === title) continue; + if (previous && previous.segmentIndex === chapter.segmentIndex) { + previous.title = title; + continue; + } + normalized.push({ title, segmentIndex: chapter.segmentIndex }); + } + + return normalized; +} + +function chapterTitleForSection(section) { + const title = cleanedTitle(section.title); + if (!title) return ''; + + const mappings = [ + [/^filing, managing, and participating in github issues$/i, 'Issues as Collaboration'], + [/^workshop recommendation/i, 'Challenge Roadmap'], + [/^chapter \d+ challenge set$/i, 'Challenge Roadmap'], + [/^challenge \d+ step-by-step:\s*(.+)$/i, (_, label) => trimChapterTitle(label)], + [/^optional extension step-by-step:\s*(.+)$/i, (_, label) => trimChapterTitle(label)], + [/^completing chapter \d+:\s*submit your evidence$/i, 'Submit Your Evidence'], + [/^expected outcomes$/i, 'What Success Looks Like'], + [/^if you get stuck$/i, 'Recovery Moves'], + [/^learning moment$/i, 'Why Issues Matter'], + [/^learning pattern used in this chapter$/i, 'The Learning Pattern'], + [/^about learning cards in this chapter$/i, 'Choose Your Learning Path'], + [/^local git alternative:/i, 'CLI Alternative'], + [/^what is a github issue\??$/i, 'Anatomy of a GitHub Issue'], + [/^navigating to the issues list$/i, 'Finding the Issues List'], + [/^the issues list page$/i, 'Reading the Issues List'], + [/^from a repository page$/i, 'Open the Issues Tab'], + [/^direct url$/i, 'Jump Straight to Issues'], + [/^page structure$/i, 'Page Structure'], + [/^how to read the issue list$/i, 'Read an Issue Row'], + [/^filtering and searching issues$/i, 'Search and Filter Issues'], + [/^using the search\/filter bar$/i, 'Filter Bar Basics'], + [/^open vs closed filter$/i, 'Open or Closed'], + [/^reading an issue$/i, 'Read the Full Issue'], + [/^landing on an issue page$/i, 'Issue Page Layout'], + [/^reading the issue description$/i, 'Read the Description'], + [/^reading comments and activity$/i, 'Comments and Activity'], + [/^leaving a comment$/i, 'Commenting and Replies'], + [/^markdown formatting while typing$/i, 'Format While You Type'], + [/^github shortcuts for the issues pages$/i, 'Useful Shortcuts'], + [/^filing a new issue$/i, 'File a New Issue'], + [/^navigating to new issue$/i, 'Open the New Issue Form'], + [/^filling out the issue form$/i, 'Write the Issue Well'], + [/^submitting the issue$/i, 'Submit the Issue'], + [/^cross-referencing issues$/i, 'Link Issues Together'], + [/^accessibility-specific issue writing tips$/i, 'Accessibility Issue Tips'], + [/^writing effective issues$/i, 'Write Better Issues'], + [/^try it:\s*(.+)$/i, (_, label) => trimChapterTitle(label)], + [/^the "good first issue" label - your entry point$/i, 'Good First Issue'], + [/^sub-issues - parent and child relationships$/i, 'Sub-Issue Relationships'] + ]; + + for (const [pattern, replacement] of mappings) { + const match = title.match(pattern); + if (!match) continue; + return trimChapterTitle(typeof replacement === 'function' ? replacement(...match) : replacement); + } + + return trimChapterTitle(title); +} + +function openingChapterTitleForEpisode(episode) { + return trimChapterTitle(`${episode.title}: Overview`); +} + +function closingChapterTitleForEpisode(episode) { + return trimChapterTitle(`${episode.title}: Wrap-Up`); +} + +function openingChapterTitleForChallenge(challenge) { + return trimChapterTitle(`Challenge ${challenge.id}: ${challenge.title}`); +} + +function closingChapterTitleForChallenge(challenge) { + return trimChapterTitle(`${challenge.title}: Final Checkpoint`); +} + +function shouldStartStructuredChapter(section) { + const title = cleanedTitle(section.title); + if (!title) return false; + if (/^learning cards?:/i.test(title)) return false; + if (/^(step-by-step|on the issues list page|on an open issue|useful filter queries|what happened|what i expected|how to reproduce|environment|quick navigation|markdown formatting while typing|title field|description \/ body field|assigning labels from the sidebar)$/i.test(title)) { + return false; + } + if (section.level <= 2) return true; + return /challenge \d+ step-by-step|optional extension step-by-step|expected outcomes|if you get stuck|learning moment|learning pattern used in this chapter|local git alternative|what is a github issue|navigating to the issues list|the issues list page|filtering and searching issues|reading an issue|leaving a comment|filing a new issue|cross-referencing issues|accessibility-specific issue writing tips|writing effective issues|the "good first issue" label - your entry point|try it:/i.test(title); +} + function scriptToSegments(script) { const segments = []; let currentSpeaker = null; @@ -135,7 +354,7 @@ function scriptToSegments(script) { return segments; } -function writeScriptAndSegments(fileName, script, group) { +function writeScriptAndSegments(fileName, script, group, chapterPlan = []) { qualityCheckScript(fileName, script); const scriptDir = path.join(SCRIPTS_DIR, group); @@ -149,6 +368,20 @@ function writeScriptAndSegments(fileName, script, group) { const segmentName = fileName.replace(/\.txt$/, '-segments.json'); const segmentPath = path.join(transcriptDir, segmentName); fs.writeFileSync(segmentPath, JSON.stringify(scriptToSegments(script), null, 2) + '\n', 'utf8'); + + const normalizedPlan = normalizeChapterPlan(chapterPlan); + if (normalizedPlan.length) { + const chapterName = fileName.replace(/\.txt$/, '-chapters.json'); + const chapterPath = path.join(transcriptDir, chapterName); + fs.writeFileSync(chapterPath, JSON.stringify({ + version: 1, + slug: path.basename(fileName, '.txt'), + chapters: normalizedPlan.map(chapter => ({ + title: chapter.title, + startSegmentIndex: chapter.segmentIndex + })) + }, null, 2) + '\n', 'utf8'); + } } function splitSentences(text) { @@ -893,7 +1126,7 @@ function createTeachingState() { }; } -function pushSpoken(lines, state, speaker, text) { +function pushSpoken(builder, state, speaker, text) { const cleaned = cleanText(text); if (!cleaned) return false; if (cleaned.length >= 80) { @@ -901,11 +1134,11 @@ function pushSpoken(lines, state, speaker, text) { if (state.usedSegments.has(key)) return false; state.usedSegments.add(key); } - lines.push(marker(speaker, cleaned)); + addSpokenLine(builder, speaker, cleaned); return true; } -function teachSection(lines, section, index, state) { +function teachSection(builder, section, index, state) { const paragraphs = uniqueItems(section.paragraphs, 4); const bullets = uniqueItems(section.bullets, 8); const steps = uniqueItems(section.steps, 8); @@ -923,8 +1156,8 @@ function teachSection(lines, section, index, state) { || index % 2 === 0; if (shouldInviteJamie) { - pushSpoken(lines, state, 'JAMIE', getJamiePrompt(section, index, state, steps.length > 0, tableRows.length > 0, codeBlocks.length > 0)); - pushSpoken(lines, state, 'ALEX', speakCoreIdea(section, paragraphs, index)); + pushSpoken(builder, state, 'JAMIE', getJamiePrompt(section, index, state, steps.length > 0, tableRows.length > 0, codeBlocks.length > 0)); + pushSpoken(builder, state, 'ALEX', speakCoreIdea(section, paragraphs, index)); } else { const bridge = choosePhrase( continuationBridges, @@ -932,27 +1165,27 @@ function teachSection(lines, section, index, state) { state.usedContinuationBridges, 'Keep the teaching thread moving.' ); - pushSpoken(lines, state, 'ALEX', `${bridge} ${speakCoreIdea(section, paragraphs, index)}`); + pushSpoken(builder, state, 'ALEX', `${bridge} ${speakCoreIdea(section, paragraphs, index)}`); } if (bullets.length) { const detailLimit = paragraphs.length >= 2 ? 4 : 6; - pushSpoken(lines, state, 'ALEX', speakDetails(bullets.slice(0, detailLimit), index, state)); + pushSpoken(builder, state, 'ALEX', speakDetails(bullets.slice(0, detailLimit), index, state)); } if (steps.length) { for (const [groupIndex, group] of chunk(steps, 4).entries()) { - if (groupIndex > 0) pushSpoken(lines, state, 'JAMIE', choosePrompt(sequencePrompts, index + groupIndex, state, section.title)); - pushSpoken(lines, state, 'ALEX', speakSteps(group, index + groupIndex)); + if (groupIndex > 0) pushSpoken(builder, state, 'JAMIE', choosePrompt(sequencePrompts, index + groupIndex, state, section.title)); + pushSpoken(builder, state, 'ALEX', speakSteps(group, index + groupIndex)); } } if (tableRows.length) { - pushSpoken(lines, state, 'ALEX', `Use the comparison to make a decision, not to recite a table. The main contrasts are: ${naturalList(tableRows)}.`); + pushSpoken(builder, state, 'ALEX', `Use the comparison to make a decision, not to recite a table. The main contrasts are: ${naturalList(tableRows)}.`); } if (codeBlocks.length) { - pushSpoken(lines, state, 'ALEX', `Treat examples as spoken recipes, not decorations. You may hear something like ${naturalList(codeBlocks)}. Read the command, understand what it changes, then run it only when the repository state matches the lesson.`); + pushSpoken(builder, state, 'ALEX', `Treat examples as spoken recipes, not decorations. You may hear something like ${naturalList(codeBlocks)}. Read the command, understand what it changes, then run it only when the repository state matches the lesson.`); } if (index > 0 && index % 5 === 2) { @@ -960,13 +1193,13 @@ function teachSection(lines, section, index, state) { const response = humanCheckResponses[index % humanCheckResponses.length]; if (!state.usedHumanChecks.has(prompt)) { state.usedHumanChecks.add(prompt); - pushSpoken(lines, state, 'JAMIE', prompt); - pushSpoken(lines, state, 'ALEX', response); + pushSpoken(builder, state, 'JAMIE', prompt); + pushSpoken(builder, state, 'ALEX', response); } } state.sectionCountSinceGeneric += 1; - addClosingPoint(lines, section, state); + addClosingPoint(builder.lines, section, state); } function buildCompanionScript(episode, total) { @@ -976,29 +1209,32 @@ function buildCompanionScript(episode, total) { .filter(entry => entry.content); const sections = sourceDocs.flatMap(doc => extractTeachingSections(doc.content)); - const lines = []; + const builder = createScriptBuilder(); + addChapterCue(builder, openingChapterTitleForEpisode(episode)); - lines.push(marker('ALEX', openingForEpisode(episode))); - lines.push(marker('JAMIE', jamieOpeningForEpisode(episode))); - lines.push(pause()); + addSpokenLine(builder, 'ALEX', openingForEpisode(episode)); + addSpokenLine(builder, 'JAMIE', jamieOpeningForEpisode(episode)); + addPauseLine(builder); - lines.push(marker('ALEX', setupTeachingFrame(episode))); - lines.push(marker('JAMIE', jamieFrameResponse(episode))); - lines.push(marker('ALEX', alexFrameResponse(episode))); - lines.push(pause()); + addSpokenLine(builder, 'ALEX', setupTeachingFrame(episode)); + addSpokenLine(builder, 'JAMIE', jamieFrameResponse(episode)); + addSpokenLine(builder, 'ALEX', alexFrameResponse(episode)); + addPauseLine(builder); const state = createTeachingState(); sections.forEach((section, index) => { - teachSection(lines, section, index, state); - if ((index + 1) % 3 === 0 || index === sections.length - 1) lines.push(pause()); + if (shouldStartStructuredChapter(section)) addChapterCue(builder, chapterTitleForSection(section)); + teachSection(builder, section, index, state); + if ((index + 1) % 3 === 0 || index === sections.length - 1) addPauseLine(builder); }); - lines.push(marker('JAMIE', 'What should people carry with them after this?')); - lines.push(marker('ALEX', 'Carry the map. Know what page or tool you are in, know which action you are taking, and know what confirmation should follow. If the confirmation is missing, pause. That pause is not wasted time; it is professional judgment.')); - lines.push(marker('JAMIE', 'That is a better way to say it than just follow the steps.')); - lines.push(marker('ALEX', `Right. Steps matter, but understanding wins. That is episode ${episode.number}. Next in the series is ${episode.number + 1 < total ? `episode ${episode.number + 1}` : 'the next learning block'}, where we keep building the same contributor muscles.`)); + addChapterCue(builder, closingChapterTitleForEpisode(episode)); + addSpokenLine(builder, 'JAMIE', 'What should people carry with them after this?'); + addSpokenLine(builder, 'ALEX', 'Carry the map. Know what page or tool you are in, know which action you are taking, and know what confirmation should follow. If the confirmation is missing, pause. That pause is not wasted time; it is professional judgment.'); + addSpokenLine(builder, 'JAMIE', 'That is a better way to say it than just follow the steps.'); + addSpokenLine(builder, 'ALEX', `Right. Steps matter, but understanding wins. That is episode ${episode.number}. Next in the series is ${episode.number + 1 < total ? `episode ${episode.number + 1}` : 'the next learning block'}, where we keep building the same contributor muscles.`); - return { fileName: `ep${pad}-${episode.slug}.txt`, script: lines.join('\n') }; + return { fileName: `ep${pad}-${episode.slug}.txt`, script: builder.lines.join('\n'), chapterPlan: builder.chapters }; } function buildChallengeScript(challenge) { @@ -1009,32 +1245,36 @@ function buildChallengeScript(challenge) { ].filter(source => source.content); const sections = sources.flatMap(source => extractTeachingSections(source.content)); - const lines = []; + const builder = createScriptBuilder(); + addChapterCue(builder, openingChapterTitleForChallenge(challenge)); - lines.push(marker('ALEX', openingForChallenge(challenge))); - lines.push(marker('JAMIE', jamieOpeningForChallenge(challenge))); - lines.push(pause()); + addSpokenLine(builder, 'ALEX', openingForChallenge(challenge)); + addSpokenLine(builder, 'JAMIE', jamieOpeningForChallenge(challenge)); + addPauseLine(builder); - lines.push(marker('ALEX', challengeTeachingFrame(challenge))); - lines.push(marker('JAMIE', jamieChallengeFrameResponse(challenge))); - lines.push(marker('ALEX', alexChallengeFrameResponse(challenge))); - lines.push(pause()); + addSpokenLine(builder, 'ALEX', challengeTeachingFrame(challenge)); + addSpokenLine(builder, 'JAMIE', jamieChallengeFrameResponse(challenge)); + addSpokenLine(builder, 'ALEX', alexChallengeFrameResponse(challenge)); + addPauseLine(builder); const state = createTeachingState(); sections.forEach((section, index) => { - teachSection(lines, section, index, state); - if ((index + 1) % 3 === 0 || index === sections.length - 1) lines.push(pause()); + if (shouldStartStructuredChapter(section)) addChapterCue(builder, chapterTitleForSection(section)); + teachSection(builder, section, index, state); + if ((index + 1) % 3 === 0 || index === sections.length - 1) addPauseLine(builder); }); - lines.push(marker('JAMIE', 'What is the final checkpoint?')); - lines.push(marker('ALEX', 'You should be able to point to the evidence, explain the action, and describe what you would do next if this were a real open source project. If you can teach the move back, you have learned it.')); - lines.push(marker('JAMIE', 'And if they get stuck?')); - lines.push(marker('ALEX', 'Read the latest message, not the loudest worry. Check the issue, the branch, the pull request, the status check, or the bot comment. Then ask for help with those facts in hand. That is how professionals collaborate.')); + addChapterCue(builder, closingChapterTitleForChallenge(challenge)); + addSpokenLine(builder, 'JAMIE', 'What is the final checkpoint?'); + addSpokenLine(builder, 'ALEX', 'You should be able to point to the evidence, explain the action, and describe what you would do next if this were a real open source project. If you can teach the move back, you have learned it.'); + addSpokenLine(builder, 'JAMIE', 'And if they get stuck?'); + addSpokenLine(builder, 'ALEX', 'Read the latest message, not the loudest worry. Check the issue, the branch, the pull request, the status check, or the bot comment. Then ask for help with those facts in hand. That is how professionals collaborate.'); - return { fileName: `cc-${challenge.id}-${challenge.slug}.txt`, script: lines.join('\n') }; + return { fileName: `cc-${challenge.id}-${challenge.slug}.txt`, script: builder.lines.join('\n'), chapterPlan: builder.chapters }; } function main() { + const args = parseArgs(process.argv.slice(2)); ensureDir(SCRIPTS_DIR); ensureDir(TRANSCRIPTS_DIR); for (const group of SCRIPT_GROUP_DIRS) { @@ -1042,28 +1282,55 @@ function main() { ensureDir(path.join(TRANSCRIPTS_DIR, group)); } - const removedScripts = removeFiles(SCRIPTS_DIR, name => name.endsWith('.txt')); - const removedSegments = removeFiles(TRANSCRIPTS_DIR, name => name.endsWith('-segments.json')); + const selectedEpisodes = episodes.filter(episode => shouldGenerateCompanion(episode, args)); + const selectedChallenges = challenges.filter(challenge => shouldGenerateChallenge(challenge, args)); + const selectedFiles = [ + ...selectedEpisodes.map(episode => `ep${String(episode.number).padStart(2, '0')}-${episode.slug}.txt`), + ...selectedChallenges.map(challenge => `cc-${challenge.id}-${challenge.slug}.txt`) + ]; + + if (!selectedFiles.length) { + console.error('No transcript targets matched the requested selection.'); + process.exitCode = 1; + return; + } + + const selectiveRun = Boolean(args.slug || Number.isInteger(args.start) || Number.isInteger(args.end) || args.group !== 'all'); + const { removedScripts, removedSegments, removedChapters } = selectiveRun + ? removeSelectedOutputs(selectedFiles) + : { + removedScripts: removeFiles(SCRIPTS_DIR, name => name.endsWith('.txt')), + removedSegments: removeFiles(TRANSCRIPTS_DIR, name => name.endsWith('-segments.json')), + removedChapters: removeFiles(TRANSCRIPTS_DIR, name => name.endsWith('-chapters.json')) + }; let companionCount = 0; - for (const episode of episodes) { - const { fileName, script } = buildCompanionScript(episode, episodes.length); - writeScriptAndSegments(fileName, script, scriptGroupForCompanion(episode)); + for (const episode of selectedEpisodes) { + const { fileName, script, chapterPlan } = buildCompanionScript(episode, episodes.length); + writeScriptAndSegments(fileName, script, scriptGroupForCompanion(episode), chapterPlan); companionCount += 1; } let challengeCount = 0; - for (const challenge of challenges) { - const { fileName, script } = buildChallengeScript(challenge); - writeScriptAndSegments(fileName, script, 'challenges'); + for (const challenge of selectedChallenges) { + const { fileName, script, chapterPlan } = buildChallengeScript(challenge); + writeScriptAndSegments(fileName, script, 'challenges', chapterPlan); challengeCount += 1; } + console.log(`Selection mode: ${selectiveRun ? 'partial' : 'full rebuild'}`); + if (args.slug) console.log(`Slug filter: ${args.slug}`); + if (Number.isInteger(args.start) || Number.isInteger(args.end)) { + console.log(`Range filter: ${Number.isInteger(args.start) ? args.start : 'start'}..${Number.isInteger(args.end) ? args.end : 'end'}`); + } + if (args.group !== 'all') console.log(`Group filter: ${args.group}`); console.log(`Removed old script files: ${removedScripts}`); console.log(`Removed old segment transcript files: ${removedSegments}`); + console.log(`Removed old chapter plan files: ${removedChapters}`); console.log(`Generated professional teaching scripts: ${companionCount}`); console.log(`Generated challenge coach scripts: ${challengeCount}`); console.log(`Generated segment JSON files: ${companionCount + challengeCount}`); + console.log(`Generated chapter plan JSON files: ${companionCount + challengeCount}`); console.log('Scripts ready for voice synthesis.'); } diff --git a/podcasts/logs/agentic-pilots/cc-02-file-your-first-issue.packet.json b/podcasts/logs/agentic-pilots/cc-02-file-your-first-issue.packet.json new file mode 100644 index 0000000..e402011 --- /dev/null +++ b/podcasts/logs/agentic-pilots/cc-02-file-your-first-issue.packet.json @@ -0,0 +1,418 @@ +{ + "generatedAt": "2026-05-13T01:47:32.141Z", + "kind": "challenge", + "slug": "cc-02-file-your-first-issue", + "title": "Challenge 02: File Your First Issue", + "description": "Finding a TODO, creating a clear issue, and explaining what needs to change.", + "transcriptPath": "S:\\code\\git-going-with-github\\podcasts\\scripts\\challenges\\cc-02-file-your-first-issue.txt", + "chapterPlanPath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-02-file-your-first-issue-chapters.json", + "transcriptText": "[ALEX]\nWelcome back to Challenge Coach. Today we are taking on File Your First Issue, one careful step at a time.\n\n[JAMIE]\nAnd I am Jamie. I am listening for the confusing parts: where to start, what to submit, and how to tell whether it worked.\n\n[PAUSE]\n\n[ALEX]\nIn this challenge, the learner is practicing finding a TODO, creating a clear issue, and explaining what needs to change. The point is not to rush. The point is to leave a clear trace of good work.\n\n[JAMIE]\nSo we should name what success sounds like before the learner starts clicking or typing.\n\n[ALEX]\nYes. When the checkpoint is clear, the learner can tell the difference between being stuck and simply not being finished yet.\n\n[PAUSE]\n\n[JAMIE]\nWhat makes this practice feel low-stakes but still real?\n\n[ALEX]\nChallenge 2: File Your First Issue: What you will do: Find a TODO comment in docs/welcome.md, then file an issue describing the problem with a clear title and description.\n\n[ALEX]\nA solid issue habit is to read the title, the body, and the timeline before acting. You are listening for the requested action, the missing evidence, and the person who needs a response.\n\n[JAMIE]\nHow would you walk the room through that step by step?\n\n[ALEX]\nInstructions has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere are the anchors worth keeping. What needs to change. Where the problem is (file name and what section). Why it matters.\n\n[ALEX]\nStart here: Open docs/welcome.md and look for a line that contains TODO -- this marks something that needs fixing. Then: Go to the Issues tab and select New issue. Next: Write a clear, descriptive title (not just \"Fix TODO\"). Last: In the description, explain. The point is not speed; the point is never losing your place.\n\n[JAMIE]\nWhat is the one idea that makes the next few steps less mysterious?\n\n[ALEX]\nThis is the move inside What makes a good issue title?: I found a TODO in docs/welcome.md that said.\n\n[JAMIE]\nThat feels much more doable when you say it as one move.\n\n[ALEX]\nRight. The magic is not speed. The magic is knowing what changed and why it matters.\n\n[PAUSE]\n\n[ALEX]\nNow bring the learner back to the room. Anchor this part on Peer simulation check. Open the Peer Simulation: Welcome Link Needs Context issue and leave a comment: Is the title clear? This is the part to say slowly: Would you know what needs fixing just from reading the title?\n\n[JAMIE]\nWhat would you say to someone who is already bracing for this to be too much?\n\n[ALEX]\nThe reason this matters is simple: in docs/welcome.md, line 15, there is a TODO comment that says \"add link to workshop schedule.\" This placeholder should be replaced with an actual link so students can find the schedule.\n\n[ALEX]\nThe useful habit is simple: orient, act, verify, then continue. That pause between action and trust is part of the work.\n\n[ALEX]\nThat matters because of the next idea. Do not treat Example 2: Feature request style as decoration. The welcome document covers what students will do but does not mention accessibility features. That is not trivia. A short section pointing students to screen reader shortcuts and keyboard navigation would help everyone start on equal footing. The workshop is closer to rehearsal than lecture. You hear the move, try the move, and then check what changed.\n\n[PAUSE]\n\n[JAMIE]\nOkay, set the room for us. What are we walking into?\n\n[ALEX]\nWhat makes a good issue has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is what that changes in practice. Clear title: Someone scanning the issue list can understand the topic without opening it. Enough context: Another person could find and understand the problem from your description alone. Reproducible location: File name and line number (if relevant) so the fix is easy to find.\n\n[ALEX]\nThis is where the talk moves from concept to action. Put Alternate approaches into plain language. Both bug reports and feature suggestions are valid for this challenge. The useful version is: The key is writing clearly enough that a stranger could act on your issue.\n\n[JAMIE]\nNow it sounds like a workflow instead of a wall of instructions.\n\n[ALEX]\nThat is where confidence comes from: not from never getting lost, but from knowing how to recover.\n\n[ALEX]\nA solid pull request habit is to separate three questions: what changed, why it changed, and what still needs review. That keeps the conversation useful instead of noisy.\n\n[JAMIE]\nWhere do you want a learner to place their attention here?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. Issues are where open source collaboration begins. That is the difference between guessing and knowing: everything from finding the right issue to file a perfect bug report - all with your keyboard and screen reader.\n\n[PAUSE]\n\n[ALEX]\nBefore the learner moves on. This part earns its place because chapter 5 is the first issue-based challenge chapter with short, confidence-building tasks. That gives the learner a foothold: it supports Challenge 2 (File Your First Issue) and Challenge 3 (Join the Conversation). That is the difference between following directions and owning the workflow.\n\n[ALEX]\nThat becomes easier when you listen for these cues. There are 2 core challenges plus one optional extension. Each challenge should take under 10 minutes. The evidence is issue comments and issue metadata. The pattern is claim - act - confirm.\n\n[JAMIE]\nGive me the sequence, because order matters here.\n\n[ALEX]\nChapter 5 Challenge Set: Chapter 5 focuses on issue skills. The next useful detail is concrete: You do NOT need to create a branch or edit any files for these challenges.\n\n[ALEX]\nFirst, create your first issue - file a new issue with a clear title and description. Then, comment and @mention - leave a comment on a classmate's issue and tag them with an @mention. After that, optional extension: Add a sub-issue - break a larger issue into smaller, trackable pieces if your repository has sub-issues enabled. Each step should leave a trace you can name.\n\n[JAMIE]\nWhat does the learner do first, second, and then after that?\n\n[ALEX]\nHere is the learner-facing version. File a new issue in your Learning Room repository with a specific title and a meaningful description. Put another way, issues are the prompts that wake up AI.\n\n[ALEX]\nHere is the part that makes the next action easier. \"Agent Request: Add missing contributor background paragraph in welcome.md\". \"Keyboard shortcuts table has incorrect NVDA modifier key\". \"Setup guide link to accessibility settings is broken\". What the problem is or what content is missing.\n\n[ALEX]\nStart here: Open your Learning Room repository in your browser. Then: Navigate to the Issues tab (press G then I to jump there with keyboard shortcuts, or find the \"Issues\" link in the repository navigation). Next: Activate the New issue button. Last: If a template picker appears, select Open a blank issue (or choose a template if one fits). If one step does not match what you hear, stop there and re-orient.\n\n[JAMIE]\nTurn that into a path someone can follow.\n\n[ALEX]\nWalk it in order: In the Title field, type a clear, specific title (at least 12 characters); In the Body field, write a meaningful description (at least 80 characters); Activate Submit new issue; and Copy the issue URL or note the issue number (for example, 150). You will reference this later. That is the rhythm: orient, act, verify, continue.\n\n[PAUSE]\n\n[JAMIE]\nWhat is the ordered workflow?\n\n[ALEX]\nThis is the move inside Challenge 3 Step-by-Step: Comment and @Mention: leave a comment on another student's issue and use an @mention to notify them. That matters in practice: the Issues tab of your Learning Room repository on GitHub.com.\n\n[ALEX]\nThese are the pieces that turn the idea into a usable move. \"@classmate I can confirm this - the link in setup-guide.md goes to a 404 page.\". \"@classmate Good catch! I think the correct shortcut is Insert+F7, not Insert+F5.\". \"@classmate I'd suggest adding the paragraph right after the 'Who Can Contribute' heading.\".\n\n[ALEX]\nWalk it in order: Open the Issues tab in your Learning Room repository; Find an issue created by a classmate (look for recent open issues, or use a facilitator-provided peer-simulation issue); Open the issue by activating its title link; and Read the issue description to understand what they reported. That is the rhythm: orient, act, verify, continue.\n\n[JAMIE]\nLet's pause on Challenge 3 Step-by-Step: Comment and @Mention. What should a learner take away from it?\n\n[ALEX]\nThink of this as 3 checks: Scroll to the comment box at the bottom of the issue; Write a helpful comment that @mentions the issue author by username; and Activate the Comment button (or press Ctrl+Enter). That small check between steps is what makes the workflow reliable.\n\n[JAMIE]\nThat is the kind of detail that keeps a screen reader user oriented.\n\n[ALEX]\nYes. The named thing - the heading, tab, field, branch, or button - is the handhold.\n\n[JAMIE]\nLet's pause on Optional Extension Step-by-Step: Add a Sub-Issue. What should a learner take away from it?\n\n[ALEX]\nAnchor this part on Optional Extension Step-by-Step: Add a Sub-Issue. Break a larger issue into smaller, trackable pieces using GitHub's sub-issue feature. This is the part to say slowly: the issue you created in Challenge 2 (or any open issue you have permission to edit). The durable skill is not memorizing one screen. It is knowing how to find your footing when the screen changes.\n\n[ALEX]\nListen for the small confirmations in this list. Sub-issue: \"Add alt text to welcome banner image\". Sub-issue: \"Fix heading hierarchy in Getting Started section\".\n\n[ALEX]\nThink of this as 4 checks: Open the issue you created in Challenge 2; Look for the Sub-issues section in the issue sidebar (right side on desktop). If you do not see it, look for an Add sub-issue button or the Create sub-issue option below the issue description; Activate Add sub-issue and choose Create new sub-issue; and Give the sub-issue a clear title that describes one specific piece of the parent issue. For example, if the parent is \"Fix accessibility in welcome.md\". That small check between steps is what makes the workflow reliable.\n\n[JAMIE]\nBefore we leave Optional Extension Step-by-Step: Add a Sub-Issue, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is add a short description and activate Create. Step two is the sub-issue now appears nested under the parent issue with a progress indicator. The sequence works because every action has a confirmation.\n\n[JAMIE]\nWhat should the learner prove to themselves after each small task?\n\n[ALEX]\nThe reason this matters is simple: when you have finished the Chapter 5 issue challenges, go to your assigned Challenge 2 or Challenge 3 issue and post a comment with your evidence. The listener should be able to check this: Replace [number] with the actual issue numbers.\n\n[PAUSE]\n\n[ALEX]\nThe next point gives the learner a handle. Expected Outcomes has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThis is where the lesson becomes something you can check. Student can create an issue with a clear title and description. Student can communicate in issue threads using @mentions. Student can organize work by breaking issues into sub-issues.\n\n[JAMIE]\nLet's pause on If You Get Stuck. What should a learner take away from it?\n\n[ALEX]\nIf You Get Stuck has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nStart here: Can't find a classmate's issue? Filter the Issues tab by is:open and look for recent ones. Then: @mention not working? Make sure you type @ immediately followed by the username with no space. Next: Sub-issue option not visible? Ask a facilitator - the feature may need to be enabled for the repository. Last: Still stuck? Ask a facilitator for a direct issue link. Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave If You Get Stuck, what is the practical point?\n\n[ALEX]\nWalk it in order: Finished but not sure you did it right? Compare your work against the Challenge 2 reference solution or the Challenge 3 reference solution. The point is not speed; the point is never losing your place.\n\n[ALEX]\nHold that next to this. Put Learning Moment into plain language. Issues are collaborative spaces, not just task lists. The useful version is: An @mention tells someone \"I need your attention here.\" Sub-issues turn vague tasks into clear checklists. The interface gets easier when it becomes a set of named places instead of a wall of controls.\n\n[JAMIE]\nSo the learner is not behind if they stop there and check the page.\n\n[ALEX]\nYes. Pausing to verify is not a detour; it is how you keep control of the workflow.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Learning Pattern Used in This Chapter. What should a learner take away from it?\n\n[ALEX]\nLearning Pattern Used in This Chapter has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThink of this as 4 checks: Start with a small, safe action (create an issue); Practice communication in public issue threads (@mention a peer); Organize work into smaller pieces (sub-issues); and Leave clear evidence in the issue timeline. Each step should leave a trace you can name.\n\n[JAMIE]\nBefore we leave Learning Pattern Used in This Chapter, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is build momentum for file editing and PR work in Chapter 6. If one step does not match what you hear, stop there and re-orient.\n\n[ALEX]\nThat connects to another useful point. This part earns its place because this chapter provides learning cards: expandable blocks that offer perspective-specific guidance for different ways of working. That gives the learner a foothold: not every card appears at every step.\n\n[JAMIE]\nWhat should they understand before typing anything?\n\n[ALEX]\nLocal Git Alternative: Working from Your Clone: If you cloned the learning-room in Block 0 and prefer working locally. The next useful detail is concrete: During Block 0 you cloned the Learning Room repository to your computer.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like cd /Documents/learning-room or wherever you cloned it; git status should show \"On branch main\". List your assigned challenge issues; gh issue list --assignee @me --label challenge; View a specific issue in the terminal; gh issue view 42; Leave a comment on an issue; gh issue comment 42 --body \"I'd like to try this!\"; Create a new issue interactively; gh. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[ALEX]\nA solid Git habit is to know which branch you are on, what changed, and what confirmation you expect before you run the next command.\n\n[PAUSE]\n\n[ALEX]\nHere is the practical turn. Here is the learner-facing version. An issue is a discussion thread attached to a repository. Put another way, every issue has a number ( 42), a state (Open or Closed), a title, a description, and a comment thread. A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[ALEX]\nOn the ground, that means a few things. Bug reports - \"This feature doesn't work when using a screen reader\". Feature requests - \"It would help if the submit button had an accessible label\". Questions - \"How do I configure X for Y use case?\". Tasks - \"Update the README with screen reader instructions\".\n\n[JAMIE]\nLet's pause on From a repository page. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside From a repository page: click the Issues tab in the repository navigation bar below the repository name. That matters in practice: The tab shows the open issue count (e.g., \"Issues · 14\").\n\n[ALEX]\nWalk it in order: Press D to navigate to the \"Repository navigation\" landmark; Press K or Tab to move through the tab links; Find \"Issues\" - it will be announced with the count: \"Issues, 14 open\"; and Press Enter to open the Issues tab. The sequence works because every action has a confirmation.\n\n[JAMIE]\nBefore we leave From a repository page, what is the practical point?\n\n[ALEX]\nThink of this as 4 checks: VO+U → Landmarks → navigate to \"Repository navigation\"; VO+Right or Quick Nav K to move through tab links; Find \"Issues\" - VoiceOver announces the count: \"Issues 14\"; and VO+Space to activate the Issues tab. Keep it that plain: know where you are, make the move, check the result.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like gh issue list. gh issue list --label \"good first issue\"; gh issue list --assignee @me; gh issue list --state closed. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nThat is a useful checkpoint before anyone starts pressing keys.\n\n[ALEX]\nExactly. Checkpoints turn uncertainty into information.\n\n[ALEX]\nKeep the thread going. Anchor this part on Direct URL. Navigate directly: https://github.com/[owner]/[repo]/issues.\n\n[PAUSE]\n\n[JAMIE]\nIf I am listening before the workshop starts, what should settle in my mind first?\n\n[ALEX]\nLearning Cards: Navigating to the Issues List has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThese are the details that keep the idea from floating away. Press D to jump to the \"Repository navigation\" landmark, then K or Tab to find the Issues link -- this is faster than arrowing through the entire page. The Issues tab announces its open count (\"Issues, 14 open\"), giving you an instant sense of project activity without loading the list. Use gh issue list in the terminal to bypass browser navigation entirely; pipe through --label or --assignee @me to pre-filter results. The Issues tab count badge may be small at default zoom; at 200%+ the tab text reflows but the count remains visible next to the word \"Issues\". Bookmark the direct URL pattern (github.com/owner/repo/issues) to skip repository page navigation altogether. In high-contrast mode, the active tab is indicated with an underline using system highlight color, not just a subtle background change.\n\n[ALEX]\nAnother way to ground it. Do not treat Page structure as decoration. Quick orientation tip: Press NVDA+F7 (or VO+U on macOS) to open a list of all headings, links, form fields, and buttons on the page. That is not trivia. This is often faster than tabbing through many elements and helps you understand the full page structure before diving in. The workshop is closer to rehearsal than lecture. You hear the move, try the move, and then check what changed.\n\n[JAMIE]\nLet's pause on How to read the issue list. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, How to read the issue list is still useful because the issues list shows each issue as a row with its title, labels, number, assignee avatars, and comment count. For someone navigating by keyboard or screen reader, this detail matters: Closed issues show a purple merged/closed badge.\n\n[ALEX]\nIf someone is taking notes, this is the short list. Issue titles are the largest text in each row and remain readable at 200%+ zoom. Label badges use colored backgrounds with text inside. In Windows High Contrast mode, labels display with system border colors and readable text rather than colored backgrounds. The Open and Closed toggle links above the list let you switch views. The active toggle is bold or underlined. The comment count icon (a speech bubble) may be small at high zoom. It appears to the right of each issue row. Hover to see \"N comments\" tooltip.\n\n[ALEX]\nStart here: Press D to reach the \"Search Results List\" landmark. Then: Press 3 (h3) to navigate by issue titles - each issue title is an h3 link. Next: Press I to move between list items if you want more detail per item. Last: Press Enter on a title to open that issue. Each step should leave a trace you can name.\n\n[JAMIE]\nBefore we leave How to read the issue list, what is the practical point?\n\n[ALEX]\nWalk it in order: VO+U → Landmarks → navigate to \"Search Results List\"; VO+Down to read through items; and H (with Quick Nav on) or VO+U → Headings to jump by issue title. If one step does not match what you hear, stop there and re-orient.\n\n[PAUSE]\n\n[ALEX]\nThis is the part worth saying out loud. Put What is announced per issue into plain language. When you navigate to an issue in the list, your screen reader will announce (in some order).\n\n[ALEX]\nThe useful version is not abstract; it sounds like this. Issue title (as a link). Issue number ( 42). Labels (e.g., \"bug, good first issue\"). Who opened it and when (\"Opened 3 days ago by username\"). Number of comments (\"5 comments\").\n\n[JAMIE]\nI like that because it gives people permission to slow down.\n\n[ALEX]\nThat is the goal. We want the page to feel explorable, not fragile.\n\n[JAMIE]\nGive me the version that sounds like an instructor, not a manual.\n\n[ALEX]\nLearning Cards: The Issues List Page has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nA few details make that real. Press D to jump to the \"Search Results List\" landmark, then press 3 to navigate issue titles (each is an H3 link). Press I to move between individual list items if you want full detail per issue (number, labels, author, age). After applying a filter, the issue list updates silently; press 3 again to re-navigate the updated list from the top. Issue titles are the largest text per row and stay readable at 200%+ zoom; labels appear as small colored badges to the right of each title. The Open/Closed toggle links are near the top of the list; the active state is bold or underlined depending on your theme. If the comment count icon (speech bubble) is too small at your zoom level, hover over it for a tooltip showing the exact count.\n\n[ALEX]\nPut that beside the next piece. This part earns its place because filtering lets you narrow the list to find the right issue quickly. That is the difference between following directions and owning the workflow.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Using the search/filter bar. What should a learner take away from it?\n\n[ALEX]\nUsing the search/filter bar has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nFirst, press F or E to jump to the filter input field (or navigate from the landmark). Then, switch to Focus Mode (NVDA+Space / Insert+Z) if not already in it. After that, type your filter or search query. Finally, press Enter to apply. The sequence works because every action has a confirmation.\n\n[JAMIE]\nLet's pause on Using the filter buttons. What should a learner take away from it?\n\n[ALEX]\nHere is the learner-facing version. Above the issue list, there is an actions toolbar with filter buttons for Labels, Milestones, Assignees, etc. Put another way, the filter buttons do not indicate the current filter state.\n\n[ALEX]\nThat shows up in the workshop in a few specific ways. The Label, Milestone, and Assignee buttons may wrap to a second row. Each button opens a dropdown with searchable options. Dropdown menus from filter buttons can extend below the visible viewport at high zoom. Scroll within the dropdown to see all options. Type in the search field at the top of each dropdown to narrow the list (for example, type \"accessibility\" in the Label dropdown). In Windows High Contrast mode, the selected filter values are indicated with a checkmark icon and system highlight color, not just a background color change.\n\n[ALEX]\nStart here: Press Tab from the search bar (or Shift+Tab from the issue list) to reach the actions toolbar. Then: Press ←/→ to move between toolbar options (Label, Milestone, Assignee, Sort). Next: Press Enter to open the selected dropdown. Last: Use ↑/↓ to navigate options in the dropdown. Keep it that plain: know where you are, make the move, check the result.\n\n[JAMIE]\nBefore we leave Using the filter buttons, what is the practical point?\n\n[ALEX]\nWalk it in order: Press Enter or Space to select; Press Escape to close (filter applies immediately); Tab forward from the search bar to reach the filter buttons, or use Quick Nav to find them; and VO+Left/Right to move between Label, Milestone, Assignee, Sort buttons. Pause after each step and listen for the confirmation before moving on.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Filter by label; gh issue list --label \"accessibility\"; Combine filters; gh issue list --label \"good first issue\" --assignee @me; Filter by milestone; gh issue list --milestone \"Hackathon Day 1\"; Search with keywords; gh issue list --search \"screen reader\". Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nLet's pause on Open vs Closed filter. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside Open vs Closed filter: the two state links \"Open\" and \"Closed\" appear near the top of the issue list. That matters in practice: Press K to navigate links until you find them, or look for them as buttons near the search bar.\n\n[JAMIE]\nThat is the part I would want someone to say out loud while they work.\n\n[ALEX]\nExactly. A learner should always know what they are trying to prove before they take the next action.\n\n[PAUSE]\n\n[ALEX]\nThis is where confidence starts to build. Learning Cards: Filtering and Searching Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nFor a learner, the useful signals are concrete. Switch to Focus Mode (NVDA+Space) before typing in the filter bar; switch back to Browse Mode after pressing Enter to read the filtered results. The filter bar does not announce how many results remain after filtering; press H to jump to the issue list heading, then listen for the count in the heading text. Combine gh issue list flags (e.g., --label \"accessibility\" --assignee @me) for instant filtered results without navigating dropdown menus. Filter dropdown menus can extend below the viewport at high zoom; scroll within the dropdown or type in the search field at the top of each dropdown to narrow options. After applying a filter, verify it took effect by checking the search bar text -- it updates to show active conditions like is:open label:accessibility. The Ctrl+/ (Windows) or Cmd+/ (Mac) shortcut focuses the search bar instantly, avoiding the need to scroll up to find it.\n\n[JAMIE]\nLet's pause on Landing on an issue page. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: when you open an issue, the page structure is.\n\n[JAMIE]\nLet's pause on Reading the issue description. What should a learner take away from it?\n\n[ALEX]\nDo not treat Reading the issue description as decoration. Browse Mode recommended: The issue detail page is primarily text-based. That is not trivia. Stay in Browse Mode (not Focus Mode) for reading - it gives you full heading (H), section (D), and link (K) navigation throughout the page.\n\n[ALEX]\nFirst, press 2 to reach the \"Description\" heading. Then, press ↓ to read the content line by line,. After that, use NVDA+↓ (NVDA say all) to have it read continuously. If one step does not match what you hear, stop there and re-orient.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like View issue in terminal (renders Markdown); gh issue view 42; Open the issue in your browser instead; gh issue view 42 --web; View just the comments; gh issue view 42 --comments. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Reading comments and activity. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, Reading comments and activity is still useful because each comment in the thread is marked as an h3. For someone navigating by keyboard or screen reader, this detail matters: Other timeline events (label added, PR linked, issue closed) appear between comments in the activity stream.\n\n[ALEX]\nThe parts worth keeping in working memory are these. Commenter's username. Timestamp (\"2 days ago\"). Body text. Reactions (if any - announced as a button with an emoji and count).\n\n[ALEX]\nNow slow down for the part people usually miss. Learning Cards: Reading an Issue has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThe room should hear these as checkpoints. Press 1 to hear the issue title, then 2 to reach \"Description\" and \"Activity\" headings, and 3 to jump between individual comments. Stay in Browse Mode for reading; only switch to Focus Mode (NVDA+Space) when you need to type in the comment box. Press D to jump to the \"Add a comment\" landmark at the bottom of the page to skip directly to the reply area. The issue title is the largest text on the page, followed by an Open/Closed badge in green or purple. Comment blocks have a subtle border and a grey header bar showing the author's avatar and timestamp; zoom in on the header to identify commenters. The sidebar (Labels, Assignees, Milestone) is on the right at desktop width; at high zoom it may move below the main content.\n\n[JAMIE]\nSo this is less about memorizing and more about noticing.\n\n[ALEX]\nRight. Once the learner can name the move, the interface becomes much less intimidating.\n\n[JAMIE]\nLet's pause on Step-by-step. What should a learner take away from it?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. To close the issue while commenting: click the arrow on the Close issue button and choose Close with comment. That is the difference between guessing and knowing: Low vision users (zoom, high contrast).\n\n[ALEX]\nThink of this as 4 checks: Scroll to the bottom of the issue page; Click in the Leave a comment text area; Type your comment (Markdown is supported - use the toolbar buttons above the text for bold, italic, code, etc.); and Optionally click Preview to see how it will render. The sequence works because every action has a confirmation.\n\n[JAMIE]\nBefore we leave Step-by-step, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is click the green Comment button to post. Step two is scroll to the bottom to find the Leave a comment text area. At 200%+ zoom, this may require significant scrolling past the timeline. Step three is the text area expands as you type. The formatting toolbar above it (bold, italic, code, etc.) wraps at high zoom but remains functional. Step four is the Preview tab next to Write lets you check Markdown rendering before posting. Keep it that plain: know where you are, make the move, check the result.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Interactive: opens your default editor ($EDITOR) to write the comment; gh issue comment 42; Inline: provide the comment text directly; gh issue comment 42 --body \"Thanks for reporting this. I can reproduce the issue with NVDA + Chrome.\". Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[PAUSE]\n\n[ALEX]\nHere is the moment where the page starts to make sense. This part earns its place because these keyboard shortcuts work inside the text area (Focus Mode).\n\n[JAMIE]\nLet's pause on GitHub shortcuts for the Issues pages. What should a learner take away from it?\n\n[ALEX]\nGitHub shortcuts for the Issues pages: These are the GitHub built-in shortcuts for working with issues. The next useful detail is concrete: Enable Focus Mode first (NVDA: NVDA+Space, JAWS: Insert+Z) before using single-key shortcuts.\n\n[ALEX]\nNow shift from knowing the term to using it. Here is the learner-facing version. Shortcut note: For G I, press G, release it, then press I (two sequential key presses, not simultaneous). A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on On an open issue. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside On an open issue: r to quote is a power move: Select any text in a comment while in Browse Mode (Shift+Arrow to select), then press R. That matters in practice: GitHub puts the quoted text in the comment box as a Markdown blockquote.\n\n[ALEX]\nWalk it in order: Navigate to your comment (3 to jump to comments); Find the \".\" (ellipsis) menu button near your comment; Press Enter on \"Edit\" from that menu; and The comment turns into a text area - switch to Focus Mode. Each step should leave a trace you can name.\n\n[JAMIE]\nBefore we leave On an open issue, what is the practical point?\n\n[ALEX]\nThink of this as 2 checks: Make your changes; and Tab to \"Update comment\" button → Enter. If one step does not match what you hear, stop there and re-orient.\n\n[ALEX]\nThe next layer is this. Learning Cards: Leaving a Comment has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Press D to jump to the \"Add a comment\" landmark, which places focus near the text area; then Enter Focus Mode to start typing. Use Ctrl+Enter to submit your comment directly from inside the text area -- this avoids having to Tab through the formatting toolbar to find the Comment button. To quote someone's text in your reply, select the text in Browse Mode (Shift+Arrow), then press R; GitHub inserts it as a blockquote in the comment box automatically. The comment text area expands as you type and is full-width at high zoom, making it easy to target; use Ctrl+Enter to submit without hunting for the Comment button. Use the Preview tab next to Write to check your Markdown formatting in rendered form before posting; bold, code blocks, and links are much easier to proofread there. Keyboard formatting shortcuts (Ctrl+B for bold, Ctrl+E for inline code) work inside the text area and save time over clicking small toolbar icons.\n\n[JAMIE]\nLet's pause on Navigating to New Issue. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: from the Issues list page, click the green New issue button in the top-right of the issue list. The listener should be able to check this: If the repository has templates, a template picker page appears - click Get started next to the template that fits your needs, or click Open a blank issue to skip templates.\n\n[ALEX]\nHere is the part to remember. At 200%+ zoom, the button may move below the search bar or wrap to its own line. It remains a prominent green button. If the repository has issue templates, a template picker page appears with each template as a card. Template descriptions may truncate at high zoom. Hover over a truncated description for the full text. The Get started button next to each template is small but uses standard link styling. Press Tab to move between templates and their Get started buttons. Open a blank issue link appears at the bottom of the template list. At high zoom, scroll down to find it.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is press K to navigate links and find the \"New issue\" button/link. Step two is press Enter. Step three is if a template picker appears: press 3 to navigate template names, read the description below each, then press Enter on \"Get started\" for the right template - or find \"Open a blank issue.\" link if no template fits. Step four is quick Nav B or VO+U → Buttons to find the \"New issue\" button. That is the rhythm: orient, act, verify, continue.\n\n[JAMIE]\nBefore we leave Navigating to New Issue, what is the practical point?\n\n[ALEX]\nFirst, vO+Space to activate it. Then, if a template picker appears: Quick Nav H or VO+Cmd+H to navigate template names, then VO+Space on \"Get started\" for the right template - or Quick Nav K to find the \"Open a blank issue\" link. That small check between steps is what makes the workflow reliable.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Do not treat Filling Out the Issue Form as decoration. The issue form has these fields (order may vary depending on the template). The workshop is closer to rehearsal than lecture. You hear the move, try the move, and then check what changed.\n\n[JAMIE]\nLet's pause on Title field. What should a learner take away from it?\n\n[ALEX]\nTitle field has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nStart here: Find the Title input field (F or by landmark). Then: Focus Mode → type a clear, specific title. Next: Good title: \"Screen reader announces wrong element count on Issues list with 50+ items\". Last: Bad title: \"Bug with screen reader\". The sequence works because every action has a confirmation.\n\n[JAMIE]\nLet's pause on Description / Body field. What should a learner take away from it?\n\n[ALEX]\nDescription / Body field has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nWalk it in order: Tab to the body text area; Focus Mode → type using the Markdown template provided; and If no template, use this structure. Keep it that plain: know where you are, make the move, check the result.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like What happened; Describe what you observed.; What I expected; Describe what should have happened.; How to reproduce; 1. Step one; 2. Step two; 3. Step three; Environment; - Screen reader: [NVDA 2025.3.3 / JAWS 2026 / VoiceOver macOS Sonoma]; - Browser: [Chrome. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Assigning labels from the sidebar. What should a learner take away from it?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. See also: Chapter 09: Labels, Milestones, and Projects covers the full label and milestone system. That is the difference between guessing and knowing: While the form is open, the sidebar has dropdowns for Labels, Assignees, and Milestone.\n\n[ALEX]\nThink of this as 4 checks: Tab away from the text area (or press Escape to leave Focus Mode); Navigate to the sidebar - press H to find \"Labels\" heading; Press Enter on the Labels gear/button; and Dropdown opens → ↑/↓ to navigate labels. Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave Assigning labels from the sidebar, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is enter to select/deselect. Step two is escape to close (selections save automatically). Step three is vO+Shift+Up to stop interacting with the text area. Step four is vO+U → Headings to find the \"Labels\" heading in the sidebar. The point is not speed; the point is never losing your place.\n\n[ALEX]\nA solid project habit is to treat metadata as decision support. Labels, status, assignees, and notifications tell you what kind of attention the work needs.\n\n[JAMIE]\nLet's pause on Submitting the issue. What should a learner take away from it?\n\n[ALEX]\nThis part earns its place because GitHub CLI (gh) alternative - filing a new issue. That gives the learner a foothold: create an issue from your terminal. That is the difference between following directions and owning the workflow.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is tab to \"Submit new issue\" button. Step two is press Enter. The point is not speed; the point is never losing your place.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Interactive: prompts for title, body, labels, and assignees; gh issue create; Inline: provide everything on the command line; gh issue create --title \"Screen reader announces wrong count on Issues list\" \\; --body \" What happened\\n\\nThe count says 14 but only. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nLet's pause on Learning Cards: Filing a New Issue. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Filing a New Issue has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. After pressing \"New issue,\" if a template picker appears, press 3 to jump between template names; each has a \"Get started\" link next to it. In the title field, type at least 12 characters for a meaningful title; press Tab to move to the body field. Press Ctrl+Enter from inside the body text area to submit the issue without needing to find the Submit button. The green \"New issue\" button is in the top-right of the Issues list page; at 200%+ zoom it may wrap below the search bar. Template cards (if the repo uses them) show truncated descriptions at high zoom; hover over them for the full text. The sidebar dropdowns for Labels, Assignees, and Milestone are gear icons that may be small at high zoom; they open searchable dropdown panels.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Tool Cards: File a New Issue. What should a learner take away from it?\n\n[ALEX]\nHere is the learner-facing version. github.dev (web editor): Not available -- issues are managed through the repository's Issues tab, not the code editor. Put another way, VS Code Desktop (GitHub Pull Requests extension).\n\n[ALEX]\nStart here: Navigate to the repository's Issues tab (or press G then I). Then: Click New issue, choose a template or blank issue. Next: Fill in the title and description, then click Submit new issue. Last: Open the GitHub panel in the sidebar. If one step does not match what you hear, stop there and re-orient.\n\n[JAMIE]\nBefore we leave Tool Cards: File a New Issue, what is the practical point?\n\n[ALEX]\nWalk it in order: Under Issues, click the + icon to create a new issue; and Fill in the title and body, then click Create. That is the rhythm: orient, act, verify, continue.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like gh issue create --title \"Your title\" --body \"Description here\"; Or interactively:; gh issue create. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nLet's pause on Cross-Referencing Issues. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside Cross-Referencing Issues: linking issues and PRs to each other creates a trail of context that helps everyone understand the project's history.\n\n[ALEX]\nKeep the teaching thread moving. Anchor this part on Closing keywords in PR descriptions or issue comments. When you type these phrases in a PR description or comment (followed by an issue number), GitHub creates a connection. The durable skill is not memorizing one screen. It is knowing how to find your footing when the screen changes.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Mentioning another issue in a comment. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: simply type followed by a number anywhere in a comment body. The listener should be able to check this: GitHub autocompletes with a dropdown of matching issues and PRs.\n\n[ALEX]\nKeep the teaching thread moving. Do not treat Cross-repo references as decoration. owner/repo 42 - references issue 42 in a different repository.\n\n[JAMIE]\nLet's pause on Learning Cards: Cross-Referencing Issues. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Cross-Referencing Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Type in any comment body to trigger GitHub's autocomplete dropdown; press Down Arrow to browse matching issues and Enter to insert the reference link. Use Closes 42 (not just 42) in PR descriptions so GitHub automatically closes the issue on merge; your screen reader will confirm the link is created in the PR timeline. Cross-references appear as timeline events on the linked issue; navigate with H to find \"mentioned this issue\" entries to trace the conversation history. Cross-reference links ( 42) render as colored, clickable links in both issue bodies and PR descriptions; at high zoom they remain inline with surrounding text. The autocomplete dropdown triggered by may overlap content at high magnification; type additional digits to narrow results and reduce dropdown size. Back-links appear automatically on the referenced issue's timeline, so you can verify the connection was created by visiting either side.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Put Sub-Issues - Parent and Child Relationships into plain language. Sub-issues (released 2025) let you nest issues inside a parent issue to break large work into tracked pieces. The useful version is: A \"parent\" issue contains a list of child issues; each child is a full issue with its own discussion, labels, and assignees. The interface gets easier when it becomes a set of named places instead of a wall of controls.\n\n[JAMIE]\nCan you translate that into plain choices?\n\n[ALEX]\nWhen to Use Sub-Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nUse the comparison to make a decision, not to recite a table. The main contrasts are: Large feature broken down means Parent: \"Redesign navigation\"; Children: \"Keyboard nav,\" \"Screen reader nav,\" \"Mobile nav\". Epic tracking means Parent: \"WCAG 2.1 AA compliance\"; Children: one issue per failing criterion. Release milestone means Parent: \"v2.0 release\"; Children: every required PR/fix.\n\n[ALEX]\nKeep the teaching thread moving. This part earns its place because the sub-issues section is announced as a region. That gives the learner a foothold: after linking, the child issue appears as a list item with a checkbox showing its open/closed state.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Reading Sub-Issues on a Parent Issue. What should a learner take away from it?\n\n[ALEX]\nReading Sub-Issues on a Parent Issue: Progress indicator: The parent issue shows a completion bar (e.g., \"3 of 7 completed\") based on how many child issues are closed. The next useful detail is concrete: Screen readers announce this as a progress region.\n\n[ALEX]\nKeep the teaching thread moving. Here is the learner-facing version. Every child issue shows a \"Parent issue\" link near the top of the page (above the description). Put another way, navigate with H or links (K) to find it. A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[JAMIE]\nLet's pause on Sub-Issues vs. Task Lists. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside Sub-Issues vs. Task Lists: if you are working on a feature that requires multiple PRs or involves several team members, ask the maintainer to create a parent issue. That matters in practice: You can then claim individual child issues without one person owning the whole feature.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Learning Cards: Sub-Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. The sub-issues section is announced as a region; press H to navigate to the \"Sub-issues\" heading, then arrow down through the list where each child announces its checkbox state, title, and open/closed badge. The parent issue shows a progress indicator (\"3 of 7 completed\") announced as a progress region; listen for this after the sub-issues heading to gauge overall status. Every child issue includes a \"Parent issue\" link near the top of its page; navigate with K (links) to find it and jump back to the parent quickly. The completion progress bar on the parent issue uses color to show progress; in high-contrast mode, completed vs. remaining segments use distinct system colors. At high zoom, the \"Add sub-issue\" button may wrap below the sub-issues list; Tab past the last child item to reach it. Each child issue's open/closed badge uses both color and text (\"Open\" or \"Closed\"), so status is readable without relying on color alone.\n\n[JAMIE]\nLet's pause on Closing an issue. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: scroll to the bottom of the issue page. The listener should be able to check this: Click the Close issue button next to the comment box.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is keyboard shortcut (fastest): Navigate to the comment text area (D → \"Add a comment\" landmark), switch to Focus Mode, then press Ctrl+Shift+Enter to close the issue. Step two is button approach: Tab to the \"Close issue\" button (at the bottom of the page, near the comment box) and press Enter. Step three is optionally leave a closing comment first. Step four is keyboard shortcut (fastest): VO+U → Landmarks → \"Add a comment\", interact with the text area (VO+Shift+Down), then press Cmd+Shift+Return to close the issue. Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave Closing an issue, what is the practical point?\n\n[ALEX]\nFirst, button approach: Quick Nav B or Tab to find the \"Close issue\" button, then VO+Space. The point is not speed; the point is never losing your place.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Close an issue; gh issue close 42; Close with a reason; gh issue close 42 --reason \"completed\"; gh issue close 42 --reason \"not planned\"; Close with a comment; gh issue close 42 --comment \"Fixed in PR 45.\"; Reopen a closed issue; gh issue reopen 42. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[ALEX]\nKeep the teaching thread moving. Do not treat Reopening a closed issue as decoration. If an issue is Closed, the \"Close issue\" button becomes \"Reopen issue\" - navigate and activate to reopen. The workshop is closer to rehearsal than lecture. You hear the move, try the move, and then check what changed.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Assigning an issue. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, Assigning an issue is still useful because GitHub CLI (gh) alternative - assigning and labeling. For someone navigating by keyboard or screen reader, this detail matters: Manage assignments and labels from your terminal.\n\n[ALEX]\nStart here: Navigate to \"Assignees\" heading (3 or H). Then: Activate the gear/plus button. Next: Type a username in the search field. Last: Select from the dropdown. Each step should leave a trace you can name.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Assign yourself; gh issue edit 42 --add-assignee @me; Add labels; gh issue edit 42 --add-label \"accessibility,in progress\"; Remove a label; gh issue edit 42 --remove-label \"needs triage\"; Set a milestone; gh issue edit 42 --milestone \"Hackathon Day 1\". Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nLet's pause on Changing labels. What should a learner take away from it?\n\n[ALEX]\nChanging labels has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nWalk it in order: Navigate to \"Labels\" heading; Activate the gear button; Select/deselect labels from the dropdown; and Press Escape to save. If one step does not match what you hear, stop there and re-orient.\n\n[JAMIE]\nLet's pause on Transferring or deleting an issue. What should a learner take away from it?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. Available from the \".\" (ellipsis) button at the top of the issue - navigate buttons with B to find it.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Learning Cards: Managing Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Close an issue instantly with Ctrl+Shift+Enter from the comment text area (Focus Mode) -- no need to Tab to the Close button. The sidebar sections (Assignees, Labels, Milestone) each have their own heading; press H or 3 to jump between them, then activate the gear icon to open each dropdown. Use gh issue edit 42 --add-label \"accessibility\" --add-assignee @me to batch-update labels and assignments from the terminal without navigating sidebar controls. Sidebar controls (Assignees, Labels, Milestone) are narrow at default width; at high zoom they stack vertically and each dropdown opens a searchable overlay that is easier to read. The Close issue button turns green and its label changes to \"Reopen issue\" once closed; in high-contrast mode, both states use distinct system colors. Type in the search field inside each sidebar dropdown (Labels, Assignees) to filter long lists rather than scrolling through all options at high magnification.\n\n[JAMIE]\nLet's pause on The \"good first issue\" Label - Your Entry Point. What should a learner take away from it?\n\n[ALEX]\nThe \"good first issue\" Label - Your Entry Point: When looking for your first open source contribution. The next useful detail is concrete: Remember: It's respectful to ask before starting.\n\n[ALEX]\nFirst, navigate to any project's Issues tab. Then, filter by label: type is:open label:\"good first issue\" in the search. After that, read through issues until you find one in your area of interest. Finally, comment on the issue: \"Hi, I'd like to work on this. Can I be assigned?\". The sequence works because every action has a confirmation.\n\n[JAMIE]\nBefore we leave The \"good first issue\" Label - Your Entry Point, what is the practical point?\n\n[ALEX]\nStart here: Wait for a maintainer to respond and assign you before starting work. Keep it that plain: know where you are, make the move, check the result.\n\n[ALEX]\nKeep the teaching thread moving. Learning Cards: The \"good first issue\" Label has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Use the filter query is:open label:\"good first issue\" in the search bar to jump directly to beginner-friendly issues; gh issue list --label \"good first issue\" does the same in the terminal. Before claiming an issue, read existing comments to check whether someone else has already been assigned; listen for \"assigned to\" in the sidebar metadata. When you comment to claim an issue, include a sentence about your approach so the maintainer can give early feedback before you start coding. The \"good first issue\" label renders with a distinct background color (typically light purple or teal); in high-contrast mode it uses system highlight colors with readable text. Filter results may include issues with multiple labels stacked together; at high zoom, labels wrap to a second line but remain readable. Bookmark the filtered URL (/issues?q=is:open+label:\"good first issue\") in your browser for one-click access to beginner issues across your favorite repositories.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Accessibility-Specific Issue Writing Tips. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside Accessibility-Specific Issue Writing Tips: when filing accessibility bugs, these details help maintainers reproduce and fix the problem.\n\n[ALEX]\nWalk it in order: Screen reader and version - \"NVDA 2025.3.3\" not just \"screen reader\"; OS and version - \"Windows 11 22H2\"; Browser and version - \"Chrome 124.0.6367.82\"; and GitHub interface - \"Modern experience (default since Jan 2026)\" or \"Classic experience (opted out)\". Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave Accessibility-Specific Issue Writing Tips, what is the practical point?\n\n[ALEX]\nThink of this as 4 checks: What was announced - quote the exact text your screen reader spoke; What should have been announced - describe the expected behavior; ARIA issue if known - e.g., \"The button has no accessible name\"; and Steps to reproduce - numbered, step-by-step. The point is not speed; the point is never losing your place.\n\n[ALEX]\nKeep the teaching thread moving. Example of a well-filed accessibility issue has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[JAMIE]\nLet's pause on Learning Cards: Accessibility-Specific Issue Writing. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Accessibility-Specific Issue Writing has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Always quote the exact text your screen reader announced in the issue body; wrap it in a fenced code block so readers know it is literal output, not your description. Include your screen reader name and version (e.g., \"NVDA 2025.3.3\") plus browser and OS; this lets maintainers reproduce with the same toolchain. Test with a second screen reader or browser if possible and note the results -- \"Also fails in JAWS 2026 with Chrome; works in VoiceOver with Safari\" dramatically narrows the debugging scope. When filing zoom or contrast bugs, state your exact zoom level and whether you use Windows High Contrast, macOS Increase Contrast, or a browser extension. Screenshots are powerful evidence; annotate them (circle the problem area, add a text callout) and always include alt text describing what the screenshot shows. Note whether the issue occurs only at certain zoom levels or viewport widths; a bug at 400% that disappears at 200% points to a CSS breakpoint problem.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Do not treat Writing Effective Issues as decoration. See also: Appendix N: Advanced Search covers search qualifiers to find existing issues before filing a new one. That is not trivia. A well-written issue saves everyone time -- the maintainer who reads it, the contributor who fixes it, and the future searcher who finds it six months later.\n\n[JAMIE]\nLet's pause on Bug Report Structure. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, Bug Report Structure is still useful because a strong bug report answers five questions. For someone navigating by keyboard or screen reader, this detail matters: Use this template every time you report something broken.\n\n[JAMIE]\nLet's pause on Feature Request Structure. What should a learner take away from it?\n\n[ALEX]\nPut Feature Request Structure into plain language. Feature requests work best when they focus on the problem before jumping to the solution. The useful version is: A feature request that starts with \"I want a dark mode toggle\" is weaker than one that starts with \"Low-vision users report eyestrain after 20 minutes because the current theme has insufficient contrast.\" The second version gives maintainers something to. The interface gets easier when it becomes a set of named places instead of a wall of controls.\n\n[ALEX]\nWalk it in order: Problem statement -- Describe the pain point. What are you trying to do, and why is it hard or impossible right now?; Proposed solution -- Your best idea for fixing the problem. Be specific enough to discuss, but hold it loosely; Alternatives considered -- Other approaches you thought about and why they fell short. This shows you have done your homework; and Who benefits -- Name the audience. \"Screen reader users navigating large repositories\" is more compelling than \"everyone.\". That small check between steps is what makes the workflow reliable.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on General Issue Writing Principles. What should a learner take away from it?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. These rules apply to every issue -- bugs, features, questions, and everything in between. That is the difference between guessing and knowing: If you discovered two bugs during the same session, file two separate issues.\n\n[ALEX]\nKeep the teaching thread moving. This part earns its place because I tried clicking and nothing happened. That gives the learner a foothold: the maintainer has to ask: What doesn't work?\n\n[JAMIE]\nLet's pause on Learning Cards: Writing Effective Issues. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Writing Effective Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Use fenced code blocks (triple backticks) when pasting error messages or screen reader output; your screen reader announces \"code block\" so listeners know the text is literal, not description. When writing \"Steps to Reproduce,\" type each step as a numbered Markdown list item (1., 2., etc.) so screen readers announce \"list with N items\". Type in the comment body to trigger issue autocomplete; press Down Arrow to navigate matching issues and Enter to insert a cross-reference link. Use the Preview tab (next to Write) to check your Markdown rendering before submitting; headings, bold text, and code blocks are much easier to proofread in rendered form. Screenshots with alt text are valuable evidence; add them with the image button in the formatting toolbar or drag-and-drop into the body field. Keep paragraphs short (3-4 sentences max) so the issue is scannable at high zoom without excessive scrolling.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Try It: File Your First Issue. What should a learner take away from it?\n\n[ALEX]\nHere is the learner-facing version. Time: 3 minutes What you need: Browser, signed in to GitHub. Put another way, go to the Learning Room repository and file a real issue. A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[ALEX]\nStart here: Navigate to the Issues tab (press G then I in Focus Mode). Then: Find and activate the \"New issue\" button (K to links, or Tab to it). Next: In the title field, type: \"Introduce myself - [Your Name]\". Last: In the description, write 2-3 sentences: who you are, what screen reader you use, and one thing you're hoping to learn today. The point is not speed; the point is never losing your place.\n\n[JAMIE]\nBefore we leave Try It: File Your First Issue, what is the practical point?\n\n[ALEX]\nWalk it in order: Press Ctrl+Enter to submit (or Tab to the Submit button and press Enter). Each step should leave a trace you can name.\n\n[JAMIE]\nLet's pause on Learning Cards: Filing Your First Issue. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside Learning Cards: Filing Your First Issue: day 2 Amplifier - Accessibility Agents: @issue-tracker File, read, comment on, and triage real issues manually before using any agent. That matters in practice: If you have not done the triage work yourself - reading descriptions, assigning labels, identifying duplicates - you cannot evaluate whether an agent's priority scoring is correct.\n\n[ALEX]\nHere is the part to remember. After pressing Ctrl+Enter to submit, listen for the page reload; GitHub navigates to your new issue page where the title is the first heading -- press 1 to confirm it matches what you typed. Navigate the issue list with 3 (heading level 3) to jump between issue titles; this is faster than arrowing through every element on the page. If the template picker appears, use Tab and Enter to select \"Open a blank issue\"; template names are announced as link text. The \"New issue\" button is prominent and green on the Issues list page; at high zoom it remains visible near the top of the page and does not collapse into a menu.\n\n[PAUSE]\n\n[JAMIE]\nWhat is the final checkpoint?\n\n[ALEX]\nYou should be able to point to the evidence, explain the action, and describe what you would do next if this were a real open source project. If you can teach the move back, you have learned it.\n\n[JAMIE]\nAnd if they get stuck?\n\n[ALEX]\nRead the latest message, not the loudest worry. Check the issue, the branch, the pull request, the status check, or the bot comment. Then ask for help with those facts in hand. That is how professionals collaborate.\n", + "chapterPlanText": "{\n \"version\": 1,\n \"slug\": \"cc-02-file-your-first-issue\",\n \"chapters\": [\n {\n \"title\": \"Opening\",\n \"startSegmentIndex\": 0\n },\n {\n \"title\": \"Challenge 2: File Your First Issue\",\n \"startSegmentIndex\": 7\n },\n {\n \"title\": \"Example 1: Bug report style\",\n \"startSegmentIndex\": 19\n },\n {\n \"title\": \"Example 2: Feature request style\",\n \"startSegmentIndex\": 21\n },\n {\n \"title\": \"What makes a good issue\",\n \"startSegmentIndex\": 23\n },\n {\n \"title\": \"Alternate approaches\",\n \"startSegmentIndex\": 26\n },\n {\n \"title\": \"Issues as Collaboration\",\n \"startSegmentIndex\": 29\n },\n {\n \"title\": \"Challenge Roadmap\",\n \"startSegmentIndex\": 32\n },\n {\n \"title\": \"Create Your First Issue\",\n \"startSegmentIndex\": 37\n },\n {\n \"title\": \"Comment and @Mention\",\n \"startSegmentIndex\": 44\n },\n {\n \"title\": \"Add a Sub-Issue\",\n \"startSegmentIndex\": 52\n },\n {\n \"title\": \"What Success Looks Like\",\n \"startSegmentIndex\": 61\n },\n {\n \"title\": \"Recovery Moves\",\n \"startSegmentIndex\": 63\n },\n {\n \"title\": \"Why Issues Matter\",\n \"startSegmentIndex\": 68\n },\n {\n \"title\": \"The Learning Pattern\",\n \"startSegmentIndex\": 72\n },\n {\n \"title\": \"CLI Alternative\",\n \"startSegmentIndex\": 78\n },\n {\n \"title\": \"What Issues Are For\",\n \"startSegmentIndex\": 82\n },\n {\n \"title\": \"Search and Filter Issues\",\n \"startSegmentIndex\": 112\n },\n {\n \"title\": \"Link Issues Together\",\n \"startSegmentIndex\": 199\n },\n {\n \"title\": \"Sub-Issue Relationships\",\n \"startSegmentIndex\": 210\n },\n {\n \"title\": \"Good First Issue\",\n \"startSegmentIndex\": 244\n },\n {\n \"title\": \"Accessibility Issue Tips\",\n \"startSegmentIndex\": 252\n },\n {\n \"title\": \"Write Better Issues\",\n \"startSegmentIndex\": 262\n },\n {\n \"title\": \"File Your First Issue\",\n \"startSegmentIndex\": 276\n },\n {\n \"title\": \"Final Checkpoint\",\n \"startSegmentIndex\": 285\n }\n ]\n}\n", + "sourceFiles": [ + { + "path": "S:\\code\\git-going-with-github\\learning-room\\.github\\ISSUE_TEMPLATE\\challenge-02-first-issue.yml", + "headings": [], + "content": "name: \"Challenge 2: File Your First Issue\"\r\ndescription: Find a TODO in the codebase and file a well-structured issue.\r\ntitle: \"Challenge 2: File Your First Issue (@{username})\"\r\nlabels: [\"challenge\", \"day-1\"]\r\nbody:\r\n - type: markdown\r\n attributes:\r\n value: |\r\n ## Challenge 2: File Your First Issue\r\n\r\n **Chapter:** [Ch05: Working with Issues](https://github.com/Community-Access/git-going-with-github/blob/main/docs/05-working-with-issues.md)\r\n\r\n **What you will do:** Find a TODO comment in `docs/welcome.md`, then file an issue describing the problem with a clear title and description.\r\n\r\n ### Instructions\r\n\r\n 1. Open `docs/welcome.md` and look for a line that contains `TODO` -- this marks something that needs fixing.\r\n 2. Go to the **Issues** tab and select **New issue**.\r\n 3. Write a clear, descriptive title (not just \"Fix TODO\").\r\n 4. In the description, explain:\r\n - **What** needs to change\r\n - **Where** the problem is (file name and what section)\r\n - **Why** it matters\r\n\r\n ### What makes a good issue title?\r\n\r\n | Instead of this | Write this |\r\n |---|---|\r\n | Fix TODO | Fix missing workshop description in welcome.md |\r\n | Bug | welcome.md TODO placeholder needs real content |\r\n | Update file | Replace TODO in welcome.md intro section with actual welcome text |\r\n\r\n - type: textarea\r\n id: evidence\r\n attributes:\r\n label: \"Your evidence\"\r\n description: \"Paste the URL of the issue you created, and explain what TODO you found and how you described it.\"\r\n placeholder: |\r\n Issue URL: https://github.com/...\r\n I found a TODO in docs/welcome.md that said...\r\n My issue title was...\r\n validations:\r\n required: true\r\n\r\n - type: markdown\r\n attributes:\r\n value: |\r\n ### Peer simulation check\r\n\r\n Open the **Peer Simulation: Welcome Link Needs Context** issue and leave a comment: Is the title clear? Would you know what needs fixing just from reading the title? If your facilitator gave you access to a real buddy repository, you may review your buddy's issue instead.\r\n\r\n ### If you get stuck\r\n\r\n | Symptom | Try this |\r\n |---|---|\r\n | I cannot find the TODO | Open `docs/welcome.md` and use your browser's find feature (Ctrl+F or Cmd+F) to search for \"TODO\". |\r\n | I am not sure what to write in the description | Describe the problem as if you are explaining it to someone who has never seen the file. |\r\n | The New issue button is not visible | Make sure you are on the Issues tab. If issues are disabled, ask your facilitator. |\r\n | I finished but want to check my work | [View the reference solution](https://github.com/Community-Access/git-going-with-github/blob/main/docs/solutions/solution-02-first-issue.md) |\r\n" + }, + { + "path": "S:\\code\\git-going-with-github\\docs\\solutions\\solution-02-first-issue.md", + "headings": [ + { + "level": 2, + "title": "Example 1: Bug report style" + }, + { + "level": 2, + "title": "Example 2: Feature request style" + }, + { + "level": 2, + "title": "What makes a good issue" + }, + { + "level": 2, + "title": "Alternate approaches" + } + ], + "content": "# Solution Reference: Challenge 2 -- File Your First Issue\r\n\r\nThis shows two example issues. Yours will look different and that is fine.\r\n\r\n## Example 1: Bug report style\r\n\r\n**Title:** TODO in welcome.md: missing workshop schedule link\r\n\r\n**Body:**\r\n\r\n> In `docs/welcome.md`, line 15, there is a TODO comment that says \"add link to workshop schedule.\" This placeholder should be replaced with an actual link so students can find the schedule.\r\n>\r\n> **Steps to find it:**\r\n> 1. Open `docs/welcome.md`\r\n> 2. Search for \"TODO\"\r\n> 3. The comment is on line 15\r\n\r\n## Example 2: Feature request style\r\n\r\n**Title:** Add accessibility tips section to welcome.md\r\n\r\n**Body:**\r\n\r\n> The welcome document covers what students will do but does not mention accessibility features. A short section pointing students to screen reader shortcuts and keyboard navigation would help everyone start on equal footing.\r\n>\r\n> **Suggested location:** After the \"What you will learn\" section.\r\n\r\n## What makes a good issue\r\n\r\n- **Clear title:** Someone scanning the issue list can understand the topic without opening it\r\n- **Enough context:** Another person could find and understand the problem from your description alone\r\n- **Reproducible location:** File name and line number (if relevant) so the fix is easy to find\r\n\r\n## Alternate approaches\r\n\r\nBoth bug reports and feature suggestions are valid for this challenge. The key is writing clearly enough that a stranger could act on your issue.\r\n" + }, + { + "path": "S:\\code\\git-going-with-github\\docs\\05-working-with-issues.md", + "headings": [ + { + "level": 2, + "title": "Filing, Managing, and Participating in GitHub Issues" + }, + { + "level": 2, + "title": "Workshop Recommendation (Chapter 5 / Challenges 2-3)" + }, + { + "level": 3, + "title": "Chapter 5 Challenge Set" + }, + { + "level": 3, + "title": "Challenge 2 Step-by-Step: Create Your First Issue" + }, + { + "level": 3, + "title": "Challenge 3 Step-by-Step: Comment and @Mention" + }, + { + "level": 3, + "title": "Optional Extension Step-by-Step: Add a Sub-Issue" + }, + { + "level": 3, + "title": "Completing Chapter 5: Submit Your Evidence" + }, + { + "level": 3, + "title": "Expected Outcomes" + }, + { + "level": 3, + "title": "If You Get Stuck" + }, + { + "level": 3, + "title": "Learning Moment" + }, + { + "level": 3, + "title": "Learning Pattern Used in This Chapter" + }, + { + "level": 3, + "title": "About Learning Cards in This Chapter" + }, + { + "level": 2, + "title": "Local Git Alternative: Working from Your Clone" + }, + { + "level": 2, + "title": "What Is a GitHub Issue?" + }, + { + "level": 2, + "title": "Navigating to the Issues List" + }, + { + "level": 3, + "title": "From a repository page" + }, + { + "level": 3, + "title": "Direct URL" + }, + { + "level": 3, + "title": "Learning Cards: Navigating to the Issues List" + }, + { + "level": 2, + "title": "The Issues List Page" + }, + { + "level": 3, + "title": "Page structure" + }, + { + "level": 3, + "title": "How to read the issue list" + }, + { + "level": 3, + "title": "What is announced per issue" + }, + { + "level": 3, + "title": "Learning Cards: The Issues List Page" + }, + { + "level": 2, + "title": "Filtering and Searching Issues" + }, + { + "level": 3, + "title": "Using the search/filter bar" + }, + { + "level": 4, + "title": "Useful filter queries" + }, + { + "level": 3, + "title": "Using the filter buttons" + }, + { + "level": 3, + "title": "Open vs Closed filter" + }, + { + "level": 3, + "title": "Learning Cards: Filtering and Searching Issues" + }, + { + "level": 2, + "title": "Reading an Issue" + }, + { + "level": 3, + "title": "Landing on an issue page" + }, + { + "level": 3, + "title": "Quick navigation" + }, + { + "level": 3, + "title": "Reading the issue description" + }, + { + "level": 3, + "title": "Reading comments and activity" + }, + { + "level": 3, + "title": "Learning Cards: Reading an Issue" + }, + { + "level": 2, + "title": "Leaving a Comment" + }, + { + "level": 3, + "title": "Step-by-step" + }, + { + "level": 3, + "title": "Markdown formatting while typing" + }, + { + "level": 3, + "title": "GitHub shortcuts for the Issues pages" + }, + { + "level": 4, + "title": "On the Issues list page" + }, + { + "level": 4, + "title": "On an open issue" + }, + { + "level": 3, + "title": "Learning Cards: Leaving a Comment" + }, + { + "level": 2, + "title": "Filing a New Issue" + }, + { + "level": 3, + "title": "Navigating to New Issue" + }, + { + "level": 3, + "title": "Filling Out the Issue Form" + }, + { + "level": 4, + "title": "Title field" + }, + { + "level": 4, + "title": "Description / Body field" + }, + { + "level": 2, + "title": "What happened" + }, + { + "level": 2, + "title": "What I expected" + }, + { + "level": 2, + "title": "How to reproduce" + }, + { + "level": 2, + "title": "Environment" + }, + { + "level": 2, + "title": "Additional context" + }, + { + "level": 3, + "title": "Assigning labels from the sidebar" + }, + { + "level": 3, + "title": "Submitting the issue" + }, + { + "level": 3, + "title": "Learning Cards: Filing a New Issue" + }, + { + "level": 3, + "title": "Tool Cards: File a New Issue" + }, + { + "level": 2, + "title": "Cross-Referencing Issues" + }, + { + "level": 3, + "title": "Closing keywords in PR descriptions or issue comments" + }, + { + "level": 3, + "title": "Mentioning another issue in a comment" + }, + { + "level": 3, + "title": "Cross-repo references" + }, + { + "level": 3, + "title": "Learning Cards: Cross-Referencing Issues" + }, + { + "level": 2, + "title": "Sub-Issues - Parent and Child Relationships" + }, + { + "level": 3, + "title": "When to Use Sub-Issues" + }, + { + "level": 3, + "title": "Creating a Sub-Issue" + }, + { + "level": 3, + "title": "Reading Sub-Issues on a Parent Issue" + }, + { + "level": 3, + "title": "Viewing a Child Issue's Parent" + }, + { + "level": 3, + "title": "Sub-Issues vs. Task Lists" + }, + { + "level": 3, + "title": "Learning Cards: Sub-Issues" + }, + { + "level": 2, + "title": "Managing Issues (for Maintainers and Triagers)" + }, + { + "level": 3, + "title": "Closing an issue" + }, + { + "level": 3, + "title": "Reopening a closed issue" + }, + { + "level": 3, + "title": "Assigning an issue" + }, + { + "level": 3, + "title": "Changing labels" + }, + { + "level": 3, + "title": "Transferring or deleting an issue" + }, + { + "level": 3, + "title": "Learning Cards: Managing Issues" + }, + { + "level": 2, + "title": "The \"good first issue\" Label - Your Entry Point" + }, + { + "level": 3, + "title": "Learning Cards: The \"good first issue\" Label" + }, + { + "level": 2, + "title": "Accessibility-Specific Issue Writing Tips" + }, + { + "level": 3, + "title": "Example of a well-filed accessibility issue" + }, + { + "level": 2, + "title": "What happened" + }, + { + "level": 2, + "title": "What I expected" + }, + { + "level": 2, + "title": "How to reproduce" + }, + { + "level": 2, + "title": "Environment" + }, + { + "level": 2, + "title": "Additional context" + }, + { + "level": 3, + "title": "Learning Cards: Accessibility-Specific Issue Writing" + }, + { + "level": 2, + "title": "Writing Effective Issues" + }, + { + "level": 3, + "title": "Bug Report Structure" + }, + { + "level": 3, + "title": "Feature Request Structure" + }, + { + "level": 3, + "title": "General Issue Writing Principles" + }, + { + "level": 3, + "title": "Before and After: A Vague Issue vs. a Clear Issue" + }, + { + "level": 3, + "title": "Learning Cards: Writing Effective Issues" + }, + { + "level": 2, + "title": "Try It: File Your First Issue" + }, + { + "level": 3, + "title": "Learning Cards: Filing Your First Issue" + } + ], + "content": "# Working with Issues\r\n>\r\n> **Listen to Episode 5:** [Working with Issues](../admin/PODCASTS.md) - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.\r\n\r\n> **Related appendices:** [Appendix N: Advanced Search](appendix-n-advanced-search.md) | [Appendix V: GitHub Mobile](appendix-v-github-mobile.md) | [Appendix B: Screen Reader Cheat Sheet](appendix-b-screen-reader-cheatsheet.md)\r\n> **Authoritative sources:** [GitHub Docs: About issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues) | [GitHub Accessibility Guide: Issues](https://accessibility.github.com/documentation/guide/issues/)\r\n\r\n\r\n## Filing, Managing, and Participating in GitHub Issues\r\n\r\n> Issues are where open source collaboration begins. This guide covers everything from finding the right issue to file a perfect bug report - all with your keyboard and screen reader.\r\n>\r\n> **Official GitHub Accessibility Guide:** GitHub publishes an NVDA-focused guide for working with issues using a screen reader at [Using GitHub Issues with a Screen Reader](https://accessibility.github.com/documentation/guide/issues/). This chapter covers the same material with additional perspectives (VoiceOver, low vision, CLI) and workshop-specific challenges. Use the official guide as a companion reference.\r\n>\r\n> **Screen reader note - New Issues Experience:** This guide uses GitHub's improved Issues experience, which provides better ARIA landmark structure and live-region announcements for screen readers. This feature may already be active for your account - it has been broadly rolled out and may no longer appear as a Feature Preview toggle at all.\r\n>\r\n> **To verify:** Activate the **User Menu** button (top-right of any GitHub page) → activate **\"Feature preview\"** → scan the list for **\"New Issues Experience\"**:\r\n>\r\n> - If listed and the toggle announces **\"Pressed\"** (or **\"Disable\"**) - already enabled, no action needed\r\n> - If listed but **not Pressed** (or **\"Enable\"**) - activate the toggle to enable it\r\n> - If not listed at all - the feature has graduated to the standard interface; it is active automatically\r\n>\r\n> Full step-by-step instructions with per-screen-reader commands are in [Pre-Workshop Setup, Step 4](00-pre-workshop-setup.md#step-4---check-github-feature-preview-settings).\r\n>\r\n> **Browse vs Focus Mode (NVDA):** Toggle between modes with `NVDA+Space` (NVDA key = `Insert` or `Caps Lock`). Use **Browse Mode** (the default) for reading lists, headings, and issue content. Switch to **Focus Mode** when typing in text fields and search boxes. Use `NVDA+F7` at any time to open a list of all headings, links, form fields, buttons, and landmarks on the page - this is your orientation tool.\r\n\r\n\r\n## Workshop Recommendation (Chapter 5 / Challenges 2-3)\r\n\r\nChapter 5 is the first **issue-based challenge chapter** with short, confidence-building tasks. It supports Challenge 2 (File Your First Issue) and Challenge 3 (Join the Conversation).\r\n\r\n- **Challenge count:** 2 core challenges plus one optional extension\r\n- **Time per challenge:** under 10 minutes\r\n- **Evidence:** issue comments and issue metadata\r\n- **Pattern:** claim -> act -> confirm\r\n\r\n### Chapter 5 Challenge Set\r\n\r\n1. **Create your first issue** - file a new issue with a clear title and description.\r\n2. **Comment and @mention** - leave a comment on a classmate's issue and tag them with an @mention.\r\n3. **Optional extension: Add a sub-issue** - break a larger issue into smaller, trackable pieces if your repository has sub-issues enabled.\r\n\r\n> **Branch guidance for Chapter 5:** Chapter 5 focuses on issue skills. You do NOT need to create a branch or edit any files for these challenges. All your work happens in GitHub issue threads. File editing and branches start in Chapter 6.\r\n>\r\n> **How completion works:** When you finish the issue challenges, post evidence in your assigned challenge issues with links to the issue you created and the comment you posted. The facilitator reviews your issue activity directly. No pull request is required for Chapter 5.\r\n\r\n### Challenge 2 Step-by-Step: Create Your First Issue\r\n\r\n**Goal:** File a new issue in your Learning Room repository with a specific title and a meaningful description.\r\n\r\n> **Agentic strategy:** Issues are the prompts that wake up AI. A clear issue for a human is also a prompt for an agent. For this challenge, log an issue describing an accessibility problem or chore you wish an AI agent could fix for you.\r\n\r\n**Where you are working:** the Issues tab of your Learning Room repository on GitHub.com.\r\n\r\n1. Open your Learning Room repository in your browser.\r\n2. Navigate to the **Issues** tab (press `G` then `I` to jump there with keyboard shortcuts, or find the \"Issues\" link in the repository navigation).\r\n3. Activate the **New issue** button.\r\n4. If a template picker appears, select **Open a blank issue** (or choose a template if one fits).\r\n5. In the **Title** field, type a clear, specific title (at least 12 characters). Examples:\r\n - \"Agent Request: Add missing contributor background paragraph in welcome.md\"\r\n - \"Keyboard shortcuts table has incorrect NVDA modifier key\"\r\n - \"Setup guide link to accessibility settings is broken\"\r\n6. In the **Body** field, write a meaningful description (at least 80 characters). Include:\r\n - What the problem is or what content is missing.\r\n - Where in the repository the problem exists (file name and section).\r\n - What you think the fix should be.\r\n7. Activate **Submit new issue**.\r\n8. Copy the issue URL or note the issue number (for example, `#150`). You will reference this later.\r\n\r\n**You are done when:** Your new issue appears in the Issues list with your username as the author, a clear title, and a detailed description.\r\n\r\n### Challenge 3 Step-by-Step: Comment and @Mention\r\n\r\n**Goal:** Leave a comment on another student's issue and use an @mention to notify them.\r\n\r\n**Where you are working:** the Issues tab of your Learning Room repository on GitHub.com.\r\n\r\n1. Open the **Issues** tab in your Learning Room repository.\r\n2. Find an issue created by a classmate (look for recent open issues, or use a facilitator-provided peer-simulation issue).\r\n3. Open the issue by activating its title link.\r\n4. Read the issue description to understand what they reported.\r\n5. Scroll to the comment box at the bottom of the issue.\r\n6. Write a helpful comment that **@mentions the issue author by username**. Examples:\r\n - \"@classmate I can confirm this - the link in setup-guide.md goes to a 404 page.\"\r\n - \"@classmate Good catch! I think the correct shortcut is Insert+F7, not Insert+F5.\"\r\n - \"@classmate I'd suggest adding the paragraph right after the 'Who Can Contribute' heading.\"\r\n7. Activate the **Comment** button (or press `Ctrl+Enter`).\r\n\r\n**Why @mentions matter:** When you type `@username`, GitHub sends that person a notification. This is how real open source teams communicate - you signal who needs to see your message. It also bridges into Chapter 10 (Notifications) where you will configure how you receive these alerts.\r\n\r\n**You are done when:** Your comment appears in the thread and includes an @mention (the username renders as a clickable link).\r\n\r\n### Optional Extension Step-by-Step: Add a Sub-Issue\r\n\r\n**Goal:** Break a larger issue into smaller, trackable pieces using GitHub's sub-issue feature.\r\n\r\n**Where you are working:** the issue you created in Challenge 2 (or any open issue you have permission to edit).\r\n\r\n> **What are sub-issues?** Sub-issues let you decompose a big task into smaller steps, each tracked independently. The parent issue shows a progress bar as sub-issues are completed. This is how teams organize real work - a single \"Fix accessibility in welcome.md\" issue might have sub-issues for each specific fix.\r\n\r\n1. Open the issue you created in Challenge 2.\r\n2. Look for the **Sub-issues** section in the issue sidebar (right side on desktop). If you do not see it, look for an **Add sub-issue** button or the **Create sub-issue** option below the issue description.\r\n3. Activate **Add sub-issue** and choose **Create new sub-issue**.\r\n4. Give the sub-issue a clear title that describes one specific piece of the parent issue. For example, if the parent is \"Fix accessibility in welcome.md\":\r\n - Sub-issue: \"Add alt text to welcome banner image\"\r\n - Sub-issue: \"Fix heading hierarchy in Getting Started section\"\r\n5. Add a short description and activate **Create**.\r\n6. The sub-issue now appears nested under the parent issue with a progress indicator.\r\n\r\n**You are done when:** Your parent issue shows at least one sub-issue in the Sub-issues section.\r\n\r\n### Completing Chapter 5: Submit Your Evidence\r\n\r\nWhen you have finished the Chapter 5 issue challenges, go to your **assigned Challenge 2 or Challenge 3 issue** and post a comment with your evidence:\r\n\r\n```text\r\nChapter 5 completed:\r\n- Challenge 2: Created issue #[number]\r\n- Challenge 3: Commented with @mention on issue #[number]\r\n- Optional: Added sub-issue to issue #[number]\r\n```\r\n\r\nReplace `[number]` with the actual issue numbers. Then close your assigned challenge issues. The facilitator will review your issue activity.\r\n\r\n### Expected Outcomes\r\n\r\n- Student can create an issue with a clear title and description.\r\n- Student can communicate in issue threads using @mentions.\r\n- Student can organize work by breaking issues into sub-issues.\r\n\r\n### If You Get Stuck\r\n\r\n1. Can't find a classmate's issue? Filter the Issues tab by `is:open` and look for recent ones.\r\n2. @mention not working? Make sure you type `@` immediately followed by the username with no space.\r\n3. Sub-issue option not visible? Ask a facilitator - the feature may need to be enabled for the repository.\r\n4. Still stuck? Ask a facilitator for a direct issue link.\r\n5. Finished but not sure you did it right? Compare your work against the [Challenge 2 reference solution](solutions/solution-02-first-issue.md) or the [Challenge 3 reference solution](solutions/solution-03-conversation.md).\r\n\r\n### Learning Moment\r\n\r\nIssues are collaborative spaces, not just task lists. An @mention tells someone \"I need your attention here.\" Sub-issues turn vague tasks into clear checklists. Both skills are used daily in real open source projects.\r\n\r\n### Learning Pattern Used in This Chapter\r\n\r\n1. Start with a small, safe action (create an issue).\r\n2. Practice communication in public issue threads (@mention a peer).\r\n3. Organize work into smaller pieces (sub-issues).\r\n4. Leave clear evidence in the issue timeline.\r\n5. Build momentum for file editing and PR work in Chapter 6.\r\n\r\n\r\n### About Learning Cards in This Chapter\r\n\r\nThis chapter provides learning cards: expandable blocks that offer perspective-specific guidance for different ways of working. Not every card appears at every step. Open the ones that match how you work.\r\n\r\nThe following table describes the five learning card types used in this chapter.\r\n\r\n| Card | Who it helps | What it covers |\r\n| --- | --- | --- |\r\n| Visual / mouse | Sighted users navigating with a mouse or trackpad | Click targets, visual cues, layout orientation |\r\n| Low vision | Users with magnification, zoom, or high-contrast themes | Zoom-friendly navigation, finding controls at high magnification, high contrast visibility |\r\n| NVDA / JAWS (Windows) | Screen reader users on Windows | Keystroke sequences, Focus and Browse mode, landmark navigation |\r\n| VoiceOver (macOS) | Screen reader users on macOS | VO key sequences, rotor usage, interaction model |\r\n| CLI (gh) | Terminal users on any platform | GitHub CLI commands for issue management |\r\n\r\n\r\n## Local Git Alternative: Working from Your Clone\r\n\r\n
\r\nIf you cloned the learning-room in Block 0 and prefer working locally\r\n\r\nDuring Block 0 you cloned the Learning Room repository to your computer. If you are comfortable in a terminal, you can use the GitHub CLI (`gh`) from inside that clone for every issue operation in this chapter. This is the same workflow covered in depth in [Chapter 11: Git and Source Control](14-git-in-practice.md).\r\n\r\n**Verify your clone is ready:**\r\n\r\n```bash\r\ncd ~/Documents/learning-room # or wherever you cloned it\r\ngit status # should show \"On branch main\"\r\n```\r\n\r\n**Common issue commands from your local terminal:**\r\n\r\n```bash\r\n# List your assigned challenge issues\r\ngh issue list --assignee @me --label challenge\r\n\r\n# View a specific issue in the terminal\r\ngh issue view 42\r\n\r\n# Leave a comment on an issue\r\ngh issue comment 42 --body \"I'd like to try this!\"\r\n\r\n# Create a new issue interactively\r\ngh issue create\r\n```\r\n\r\nAll of these produce the same result as the web interface. The chapter instructions work identically either way - choose whichever is more comfortable for you.\r\n\r\n
\r\n\r\n\r\n## What Is a GitHub Issue?\r\n\r\nAn issue is a discussion thread attached to a repository. Issues are used for:\r\n\r\n- **Bug reports** - \"This feature doesn't work when using a screen reader\"\r\n- **Feature requests** - \"It would help if the submit button had an accessible label\"\r\n- **Questions** - \"How do I configure X for Y use case?\"\r\n- **Tasks** - \"Update the README with screen reader instructions\"\r\n- **Accessibility reports** - \"The infinite scroll carousel is not keyboard accessible\"\r\n\r\nEvery issue has a **number** (`#42`), a **state** (Open or Closed), a **title**, a **description**, and a **comment thread**. Issues are public by default on public repositories.\r\n\r\n> **Learning Room connection:** In your Learning Room repo, every challenge from `docs/CHALLENGES.md` becomes an issue. For example, Challenge 1 (\"Fix Broken Link\") is filed as an issue pointing to `docs/welcome.md`, describing the broken link and linking to the challenge success criteria. When you open a PR to fix it, you reference the issue with `Closes #XX` to automatically close it on merge.\r\n\r\n\r\n## Navigating to the Issues List\r\n\r\n### From a repository page\r\n\r\n
\r\nVisual / mouse users\r\n\r\nClick the **Issues** tab in the repository navigation bar below the repository name. The tab shows the open issue count (e.g., “Issues · 14”).\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. Press `D` to navigate to the \"Repository navigation\" landmark\r\n2. Press `K` or `Tab` to move through the tab links\r\n3. Find \"Issues\" - it will be announced with the count: \"Issues, 14 open\"\r\n4. Press `Enter` to open the Issues tab\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. `VO+U` → Landmarks → navigate to \"Repository navigation\"\r\n2. `VO+Right` or Quick Nav `K` to move through tab links\r\n3. Find \"Issues\" - VoiceOver announces the count: \"Issues 14\"\r\n4. `VO+Space` to activate the Issues tab\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative\r\n\r\nList open issues directly from your terminal:\r\n\r\n```bash\r\ngh issue list\r\n```\r\n\r\nFilter by label, assignee, or state:\r\n\r\n```bash\r\ngh issue list --label \"good first issue\"\r\ngh issue list --assignee @me\r\ngh issue list --state closed\r\n```\r\n\r\n**Setup:** Install the GitHub CLI from [cli.github.com](https://cli.github.com) and authenticate with `gh auth login`. See [Appendix D](appendix-d-git-authentication.md) for details.\r\n\r\n
\r\n\r\n### Direct URL\r\n\r\nNavigate directly: `https://github.com/[owner]/[repo]/issues`\r\n\r\n### Learning Cards: Navigating to the Issues List\r\n\r\n**Screen reader users:**\r\n- Press `D` to jump to the \"Repository navigation\" landmark, then `K` or `Tab` to find the Issues link -- this is faster than arrowing through the entire page\r\n- The Issues tab announces its open count (\"Issues, 14 open\"), giving you an instant sense of project activity without loading the list\r\n- Use `gh issue list` in the terminal to bypass browser navigation entirely; pipe through `--label` or `--assignee @me` to pre-filter results\r\n\r\n**Low-vision users:**\r\n- The Issues tab count badge may be small at default zoom; at 200%+ the tab text reflows but the count remains visible next to the word \"Issues\"\r\n- Bookmark the direct URL pattern (`github.com/owner/repo/issues`) to skip repository page navigation altogether\r\n- In high-contrast mode, the active tab is indicated with an underline using system highlight color, not just a subtle background change\r\n\r\n**Sighted users:**\r\n- The Issues tab sits in the repository navigation bar directly below the repo name; the open count badge gives a quick pulse check on project health\r\n- Memorize the `G I` keyboard shortcut (press G, release, press I) to jump to Issues from anywhere in the repository without scrolling\r\n- The direct URL pattern works for any repository: swap `[owner]/[repo]` with real values and bookmark your most visited projects\r\n\r\n\r\n## The Issues List Page\r\n\r\n### Page structure\r\n\r\n```\r\n[Search / filter bar] -- controls at the top\r\n[State tabs: Open / Closed] -- filter by status\r\n[Issues list] -- each issue is one list item or heading\r\n[Pagination] -- at the bottom\r\n```\r\n\r\n> **Quick orientation tip:** Press `NVDA+F7` (or `VO+U` on macOS) to open a list of all headings, links, form fields, and buttons on the page. This is often faster than tabbing through many elements and helps you understand the full page structure before diving in. Use `Ctrl+/` (Windows) or `Cmd+/` (Mac) to jump directly to the search field from anywhere on the page.\r\n\r\n### How to read the issue list\r\n\r\n
\r\nVisual / mouse users\r\n\r\nThe issues list shows each issue as a row with its title, labels, number, assignee avatars, and comment count. Closed issues show a purple merged/closed badge. Click any issue title to open it. Use the **Open** and **Closed** toggle links above the list to switch between states.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nEach issue row shows the title, labels (colored badges), number, and comment count. At high magnification:\r\n\r\n- Issue titles are the largest text in each row and remain readable at 200%+ zoom.\r\n- Label badges use colored backgrounds with text inside. In Windows High Contrast mode, labels display with system border colors and readable text rather than colored backgrounds.\r\n- The **Open** and **Closed** toggle links above the list let you switch views. The active toggle is bold or underlined.\r\n- The comment count icon (a speech bubble) may be small at high zoom. It appears to the right of each issue row. Hover to see \"N comments\" tooltip.\r\n- Use `Ctrl+F` (browser Find) to search for a specific issue title if the list is long.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS)\r\n\r\n1. Press `D` to reach the “Search Results List” landmark\r\n2. Press `3` (h3) to navigate by issue titles - each issue title is an h3 link\r\n3. Press `I` to move between list items if you want more detail per item\r\n4. Press `Enter` on a title to open that issue\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver)\r\n\r\n1. `VO+U` → Landmarks → navigate to “Search Results List”\r\n2. `VO+Down` to read through items\r\n3. `H` (with Quick Nav on) or `VO+U` → Headings to jump by issue title\r\n\r\n
\r\n\r\n### What is announced per issue\r\n\r\nWhen you navigate to an issue in the list, your screen reader will announce (in some order):\r\n\r\n- Issue title (as a link)\r\n- Issue number (`#42`)\r\n- Labels (e.g., \"bug, good first issue\")\r\n- Who opened it and when (\"Opened 3 days ago by username\")\r\n- Number of comments (\"5 comments\")\r\n\r\n### Learning Cards: The Issues List Page\r\n\r\n
\r\nScreen reader users\r\n\r\n- Press `D` to jump to the \"Search Results List\" landmark, then press `3` to navigate issue titles (each is an H3 link)\r\n- Press `I` to move between individual list items if you want full detail per issue (number, labels, author, age)\r\n- After applying a filter, the issue list updates silently; press `3` again to re-navigate the updated list from the top\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- Issue titles are the largest text per row and stay readable at 200%+ zoom; labels appear as small colored badges to the right of each title\r\n- The Open/Closed toggle links are near the top of the list; the active state is bold or underlined depending on your theme\r\n- If the comment count icon (speech bubble) is too small at your zoom level, hover over it for a tooltip showing the exact count\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- Each issue row shows: open/closed icon (green circle = open, purple merged icon = closed), title, label badges, PR link icon, comment count, and assignee avatar\r\n- Click the Open/Closed tabs above the list to switch between open and closed issues; the count next to each tab updates as you filter\r\n- Issue labels appear as colored rounded rectangles inline with the title; hover over a label to see its description\r\n\r\n
\r\n\r\n\r\n## Filtering and Searching Issues\r\n\r\nFiltering lets you narrow the list to find the right issue quickly.\r\n\r\n### Using the search/filter bar\r\n\r\n1. Press `F` or `E` to jump to the filter input field (or navigate from the landmark)\r\n2. Switch to Focus Mode (`NVDA+Space` / `Insert+Z`) if not already in it\r\n3. Type your filter or search query\r\n4. Press `Enter` to apply\r\n\r\n#### Useful filter queries\r\n\r\n```text\r\nis:open label:\"good first issue\" ← great for finding your first contribution\r\nis:open label:accessibility ← accessibility-related open issues\r\nis:open assignee:@me ← issues assigned to you\r\nis:open no:assignee ← unassigned issues\r\nis:open author:@me ← issues you filed\r\nmentions:@me ← where you were @mentioned\r\nis:open is:unread ← issues with unread activity\r\n```\r\n\r\n### Using the filter buttons\r\n\r\nAbove the issue list, there is an **actions toolbar** with filter buttons for Labels, Milestones, Assignees, etc.\r\n\r\n> **Screen reader note:** The filter buttons do not indicate the current filter state. After applying a filter, the button text does not change to reflect what is selected. To verify which filters are active, check the search/filter bar text - it updates to show the active filter conditions (for example, `is:open label:accessibility`).\r\n\r\n
\r\nVisual / mouse users\r\n\r\nThe filter bar sits above the issue list. Click **Label**, **Milestone**, or **Assignee** to open a dropdown, select the values you want, then click anywhere outside to close. The issue list updates immediately.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nThe filter bar sits above the issue list. At high magnification:\r\n\r\n- The **Label**, **Milestone**, and **Assignee** buttons may wrap to a second row. Each button opens a dropdown with searchable options.\r\n- Dropdown menus from filter buttons can extend below the visible viewport at high zoom. Scroll within the dropdown to see all options.\r\n- Type in the search field at the top of each dropdown to narrow the list (for example, type \"accessibility\" in the Label dropdown).\r\n- In Windows High Contrast mode, the selected filter values are indicated with a checkmark icon and system highlight color, not just a background color change.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. Press `Tab` from the search bar (or `Shift+Tab` from the issue list) to reach the actions toolbar\r\n2. Press `←/→` to move between toolbar options (Label, Milestone, Assignee, Sort)\r\n3. Press `Enter` to open the selected dropdown\r\n4. Use `↑/↓` to navigate options in the dropdown\r\n5. Press `Enter` or `Space` to select\r\n6. Press `Escape` to close (filter applies immediately)\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. `Tab` forward from the search bar to reach the filter buttons, or use Quick Nav to find them\r\n2. `VO+Left/Right` to move between Label, Milestone, Assignee, Sort buttons\r\n3. `VO+Space` to open the selected dropdown\r\n4. `VO+Down` or arrow keys to navigate the dropdown options\r\n5. `VO+Space` to select/deselect\r\n6. `Escape` to close (filter applies immediately)\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative - filtering\r\n\r\nFilter issues by label, milestone, or assignee without navigating dropdown menus:\r\n\r\n```bash\r\n# Filter by label\r\ngh issue list --label \"accessibility\"\r\n\r\n# Combine filters\r\ngh issue list --label \"good first issue\" --assignee @me\r\n\r\n# Filter by milestone\r\ngh issue list --milestone \"Hackathon Day 1\"\r\n\r\n# Search with keywords\r\ngh issue list --search \"screen reader\"\r\n```\r\n\r\n
\r\n\r\n### Open vs Closed filter\r\n\r\nThe two state links \"Open\" and \"Closed\" appear near the top of the issue list. Press `K` to navigate links until you find them, or look for them as buttons near the search bar.\r\n\r\n### Learning Cards: Filtering and Searching Issues\r\n\r\n**Screen reader users:**\r\n- Switch to Focus Mode (`NVDA+Space`) before typing in the filter bar; switch back to Browse Mode after pressing Enter to read the filtered results\r\n- The filter bar does not announce how many results remain after filtering; press `H` to jump to the issue list heading, then listen for the count in the heading text\r\n- Combine `gh issue list` flags (e.g., `--label \"accessibility\" --assignee @me`) for instant filtered results without navigating dropdown menus\r\n\r\n**Low-vision users:**\r\n- Filter dropdown menus can extend below the viewport at high zoom; scroll within the dropdown or type in the search field at the top of each dropdown to narrow options\r\n- After applying a filter, verify it took effect by checking the search bar text -- it updates to show active conditions like `is:open label:accessibility`\r\n- The `Ctrl+/` (Windows) or `Cmd+/` (Mac) shortcut focuses the search bar instantly, avoiding the need to scroll up to find it\r\n\r\n**Sighted users:**\r\n- Build compound queries in the search bar for precision: `is:open label:\"good first issue\" no:assignee` finds unclaimed starter issues in one step\r\n- The Open/Closed toggle near the top of the list preserves your current filter; click Closed to see resolved issues without losing your label or assignee filter\r\n- Pin your most-used filter as a browser bookmark (the URL updates to reflect the active query) for one-click access\r\n\r\n\r\n## Reading an Issue\r\n\r\n### Landing on an issue page\r\n\r\nWhen you open an issue, the page structure is:\r\n\r\n```text\r\n[Issue title - h1]\r\n[Open/Closed status badge]\r\n[Author, timestamp, comment count]\r\n─────────────────────────────────\r\n[Issue description - Main content] ← the original post\r\n[Labels, Assignees sidebar - h3s]\r\n─────────────────────────────────\r\n[Activity / Timeline] ← comments and events\r\n [First comment - h3]\r\n [Second comment - h3]\r\n ...\r\n─────────────────────────────────\r\n[Add a comment - landmark]\r\n[Comment text area]\r\n[Close issue / Submit button]\r\n```\r\n\r\n### Quick navigation\r\n\r\n| Goal | Key |\r\n| ------ | ----- |\r\n| Hear the issue title | `1` |\r\n| Jump to description | `2` (first h2 is usually \"Description\") |\r\n| Jump to Activity section | `2` → next h2 is \"Activity\" |\r\n| Navigate between comments | `3` (each comment is h3) |\r\n| Jump to comment box | `D` → \"Add a comment\" landmark |\r\n| Navigate labels/assignees | `H` or `3` in the sidebar |\r\n\r\n### Reading the issue description\r\n\r\n1. Press `2` to reach the \"Description\" heading\r\n2. Press `↓` to read the content line by line, OR\r\n3. Use `NVDA+↓` (NVDA say all) to have it read continuously\r\n\r\n> **Browse Mode recommended:** The issue detail page is primarily text-based. Stay in **Browse Mode** (not Focus Mode) for reading - it gives you full heading (`H`), section (`D`), and link (`K`) navigation throughout the page. Only switch to Focus Mode when you need to type in a comment box.\r\n\r\nMarkdown in the description renders as proper HTML: headings become actual headings, bullets become lists, code blocks become `` elements with the text \"code block\" announced.\r\n\r\n
\r\nGitHub CLI (gh) alternative - reading an issue\r\n\r\nView an issue's full content in your terminal:\r\n\r\n```bash\r\n# View issue in terminal (renders Markdown)\r\ngh issue view 42\r\n\r\n# Open the issue in your browser instead\r\ngh issue view 42 --web\r\n\r\n# View just the comments\r\ngh issue view 42 --comments\r\n```\r\n\r\nThe terminal output includes the title, state, labels, assignees, body, and comments. Markdown renders as plain text - headings use `#` symbols, lists use `-`, and code blocks are preserved.\r\n\r\n
\r\n\r\n### Reading comments and activity\r\n\r\nEach comment in the thread is marked as an h3. Navigate between them with `3`.\r\n\r\nEach comment announces:\r\n\r\n- Commenter's username\r\n- Timestamp (\"2 days ago\")\r\n- Body text\r\n- Reactions (if any - announced as a button with an emoji and count)\r\n- A \"Reply\" link\r\n\r\nOther timeline events (label added, PR linked, issue closed) appear between comments in the activity stream. They are typically announced as text paragraphs.\r\n\r\n### Learning Cards: Reading an Issue\r\n\r\n
\r\nScreen reader users\r\n\r\n- Press `1` to hear the issue title, then `2` to reach \"Description\" and \"Activity\" headings, and `3` to jump between individual comments\r\n- Stay in Browse Mode for reading; only switch to Focus Mode (`NVDA+Space`) when you need to type in the comment box\r\n- Press `D` to jump to the \"Add a comment\" landmark at the bottom of the page to skip directly to the reply area\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- The issue title is the largest text on the page, followed by an Open/Closed badge in green or purple\r\n- Comment blocks have a subtle border and a grey header bar showing the author's avatar and timestamp; zoom in on the header to identify commenters\r\n- The sidebar (Labels, Assignees, Milestone) is on the right at desktop width; at high zoom it may move below the main content\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- The issue page has a two-column layout: main content on the left (description, timeline, comment box) and sidebar on the right (labels, assignees, milestone, linked PRs)\r\n- Each comment shows the author's avatar in the left margin, with a header bar containing their username and a relative timestamp\r\n- Timeline events (label changes, assignments, cross-references) appear as small lines between comments with icons indicating the event type\r\n\r\n
\r\n\r\n\r\n## Leaving a Comment\r\n\r\n### Step-by-step\r\n\r\n
\r\nVisual / mouse users\r\n\r\n1. Scroll to the bottom of the issue page\r\n2. Click in the **Leave a comment** text area\r\n3. Type your comment (Markdown is supported - use the toolbar buttons above the text for bold, italic, code, etc.)\r\n4. Optionally click **Preview** to see how it will render\r\n5. Click the green **Comment** button to post\r\n\r\nTo close the issue while commenting: click the arrow on the **Close issue** button and choose **Close with comment**.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nThe comment area is at the bottom of the issue page. At high magnification:\r\n\r\n1. Scroll to the bottom to find the **Leave a comment** text area. At 200%+ zoom, this may require significant scrolling past the timeline.\r\n2. The text area expands as you type. The formatting toolbar above it (bold, italic, code, etc.) wraps at high zoom but remains functional.\r\n3. The **Preview** tab next to **Write** lets you check Markdown rendering before posting.\r\n4. The green **Comment** button is full-width at high zoom and easy to target.\r\n5. **Keyboard shortcut:** Press `Ctrl+Enter` (Windows) or `Cmd+Return` (macOS) from inside the text area to submit the comment without finding the button.\r\n6. In Windows High Contrast mode, the text area border and the Comment button use system colors for clear visibility.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. Navigate to the comment box: `D` → \"Add a comment\" landmark, or press `E` or `F` to focus the text area\r\n2. Enter Focus Mode: NVDA: `Insert+Space` | JAWS: `Insert+Z`\r\n3. Type your comment (plain text or Markdown)\r\n4. To preview: `Tab` to the **Preview** button, press `Enter`; then `Tab` back to **Write** to continue editing\r\n5. Submit: press `Ctrl+Enter` from inside the text area, OR press `Escape` → `Tab` to the **Comment** button → `Enter`\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. Navigate to the comment box: `VO+U` → Landmarks → \"Add a comment\", or Quick Nav `F` to jump to the text area\r\n2. Interact with the text area: `VO+Shift+Down`\r\n3. Type your comment (plain text or Markdown)\r\n4. To preview: `VO+Shift+Up` to stop interacting, then `Tab` to the **Preview** button and `VO+Space`\r\n5. Submit: press `Cmd+Return` from inside the text area, OR `VO+Shift+Up` → `Tab` to the **Comment** button → `VO+Space`\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative - commenting\r\n\r\nLeave a comment from your terminal:\r\n\r\n```bash\r\n# Interactive: opens your default editor ($EDITOR) to write the comment\r\ngh issue comment 42\r\n\r\n# Inline: provide the comment text directly\r\ngh issue comment 42 --body \"Thanks for reporting this. I can reproduce the issue with NVDA + Chrome.\"\r\n```\r\n\r\n
\r\n\r\n### Markdown formatting while typing\r\n\r\nThese keyboard shortcuts work inside the text area (Focus Mode):\r\n\r\n| Shortcut | Result |\r\n| ---------- | -------- |\r\n| `Ctrl+B` | **Bold text** |\r\n| `Ctrl+I` | *Italic text* |\r\n| `Ctrl+E` | `Code span` |\r\n| `Ctrl+K` | [Link text](URL) dialog |\r\n| `Ctrl+Shift+.` | > Blockquote |\r\n| `Ctrl+Shift+L` | - Bullet list |\r\n| `Ctrl+Shift+7` | 1. Numbered list |\r\n\r\n### GitHub shortcuts for the Issues pages\r\n\r\nThese are the GitHub built-in shortcuts for working with issues. Enable Focus Mode first (NVDA: `NVDA+Space`, JAWS: `Insert+Z`) before using single-key shortcuts.\r\n\r\n#### On the Issues list page\r\n\r\n| Shortcut | Action |\r\n| --- | --- |\r\n| `?` | Show all shortcuts for this page |\r\n| `G I` | Jump to the Issues tab from anywhere in the repo |\r\n| `C` | Create a new issue |\r\n\r\n**Shortcut note:** For `G I`, press `G`, release it, then press `I` (two sequential key presses, not simultaneous).\r\n| `Ctrl+/` (Win) or `Cmd+/` (Mac) | Focus the issues search and filter bar |\r\n| `U` | Filter by author |\r\n| `L` | Filter by or edit labels |\r\n| `M` | Filter by or edit milestones |\r\n| `A` | Filter by or edit assignee |\r\n| `O` or `Enter` | Open the selected issue |\r\n\r\n#### On an open issue\r\n\r\n| Shortcut | Action |\r\n| --- | --- |\r\n| `M` | Set a milestone |\r\n| `L` | Apply a label |\r\n| `A` | Set an assignee |\r\n| `X` | Link a related issue from the same repository |\r\n| `R` | Quote selected text in your reply (select text first) |\r\n| `Ctrl+Shift+P` (Win) or `Cmd+Shift+P` (Mac) | Toggle Write and Preview tabs |\r\n| `Ctrl+Enter` | Submit comment from inside the text area |\r\n\r\n> **`R` to quote is a power move:** Select any text in a comment while in Browse Mode (`Shift+Arrow` to select), then press `R`. GitHub puts the quoted text in the comment box as a Markdown blockquote. Much faster than typing `>` manually.\r\n\r\nFor the full shortcut system, see [Screen Reader Cheat Sheet - GitHub Shortcuts section](appendix-b-screen-reader-cheatsheet.md#github-built-in-keyboard-shortcuts).\r\n\r\n1. Navigate to your comment (`3` to jump to comments)\r\n2. Find the \"...\" (ellipsis) menu button near your comment\r\n3. Press `Enter` on \"Edit\" from that menu\r\n4. The comment turns into a text area - switch to Focus Mode\r\n5. Make your changes\r\n6. Tab to \"Update comment\" button → Enter\r\n\r\n### Learning Cards: Leaving a Comment\r\n\r\n**Screen reader users:**\r\n- Press `D` to jump to the \"Add a comment\" landmark, which places focus near the text area; then Enter Focus Mode to start typing\r\n- Use `Ctrl+Enter` to submit your comment directly from inside the text area -- this avoids having to Tab through the formatting toolbar to find the Comment button\r\n- To quote someone's text in your reply, select the text in Browse Mode (`Shift+Arrow`), then press `R`; GitHub inserts it as a blockquote in the comment box automatically\r\n\r\n**Low-vision users:**\r\n- The comment text area expands as you type and is full-width at high zoom, making it easy to target; use `Ctrl+Enter` to submit without hunting for the Comment button\r\n- Use the Preview tab next to Write to check your Markdown formatting in rendered form before posting; bold, code blocks, and links are much easier to proofread there\r\n- Keyboard formatting shortcuts (`Ctrl+B` for bold, `Ctrl+E` for inline code) work inside the text area and save time over clicking small toolbar icons\r\n\r\n**Sighted users:**\r\n- The formatting toolbar above the text area offers bold, italic, code, link, and list buttons; hover for tooltips showing the keyboard shortcut for each\r\n- Use the `R` shortcut to quote selected text -- it creates a blockquote in your reply, making threaded conversations much easier to follow\r\n- The Close with comment option (dropdown arrow on the Close button) lets you leave a final note and close the issue in a single action\r\n\r\n\r\n## Filing a New Issue\r\n\r\n### Navigating to New Issue\r\n\r\n
\r\nVisual / mouse users\r\n\r\nFrom the Issues list page, click the green **New issue** button in the top-right of the issue list. If the repository has templates, a template picker page appears - click **Get started** next to the template that fits your needs, or click **Open a blank issue** to skip templates.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nThe green **New issue** button is in the top-right of the issue list page. At high magnification:\r\n\r\n- At 200%+ zoom, the button may move below the search bar or wrap to its own line. It remains a prominent green button.\r\n- If the repository has issue templates, a template picker page appears with each template as a card. Template descriptions may truncate at high zoom. Hover over a truncated description for the full text.\r\n- The **Get started** button next to each template is small but uses standard link styling. Press `Tab` to move between templates and their Get started buttons.\r\n- **Open a blank issue** link appears at the bottom of the template list. At high zoom, scroll down to find it.\r\n- In Windows High Contrast mode, the New issue button uses the system button colors and the template cards have visible borders.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\nFrom the Issues list:\r\n\r\n1. Press `K` to navigate links and find the \"New issue\" button/link\r\n2. Press `Enter`\r\n3. If a template picker appears: press `3` to navigate template names, read the description below each, then press `Enter` on \"Get started\" for the right template - or find \"Open a blank issue.\" link if no template fits\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\nFrom the Issues list:\r\n\r\n1. Quick Nav `B` or `VO+U` → Buttons to find the \"New issue\" button\r\n2. `VO+Space` to activate it\r\n3. If a template picker appears: Quick Nav `H` or `VO+Cmd+H` to navigate template names, then `VO+Space` on \"Get started\" for the right template - or Quick Nav `K` to find the \"Open a blank issue\" link\r\n\r\n
\r\n\r\n### Filling Out the Issue Form\r\n\r\nThe issue form has these fields (order may vary depending on the template):\r\n\r\n#### Title field\r\n\r\n1. Find the Title input field (`F` or by landmark)\r\n2. Focus Mode → type a clear, specific title\r\n3. Good title: \"Screen reader announces wrong element count on Issues list with 50+ items\"\r\n4. Bad title: \"Bug with screen reader\"\r\n\r\n#### Description / Body field\r\n\r\n1. Tab to the body text area\r\n2. Focus Mode → type using the Markdown template provided\r\n3. If no template, use this structure:\r\n\r\n```markdown\r\n## What happened\r\n\r\nDescribe what you observed.\r\n\r\n## What I expected\r\n\r\nDescribe what should have happened.\r\n\r\n## How to reproduce\r\n\r\n1. Step one\r\n2. Step two\r\n3. Step three\r\n\r\n## Environment\r\n\r\n- Screen reader: [NVDA 2025.3.3 / JAWS 2026 / VoiceOver macOS Sonoma]\r\n- Browser: [Chrome 124 / Firefox 125 / Safari 17]\r\n- OS: [Windows 11 / macOS 14]\r\n- GitHub interface: [Modern experience (default since Jan 2026) / Classic experience]\r\n\r\n## Additional context\r\n\r\nAny other information, screenshots (with alt text), or links.\r\n```\r\n\r\n### Assigning labels from the sidebar\r\n\r\n> **See also:** [Chapter 09: Labels, Milestones, and Projects](09-labels-milestones-projects.md) covers the full label and milestone system.\r\n\r\nWhile the form is open, the sidebar has dropdowns for Labels, Assignees, and Milestone.\r\n\r\n
\r\nVisual / mouse users\r\n\r\nIn the right sidebar, click the gear icon () next to **Labels**. A dropdown opens - click a label to select it. Click outside to close. Repeat for **Assignees** and **Milestone**.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. `Tab` away from the text area (or press `Escape` to leave Focus Mode)\r\n2. Navigate to the sidebar - press `H` to find \"Labels\" heading\r\n3. Press `Enter` on the Labels gear/button\r\n4. Dropdown opens → `↑/↓` to navigate labels\r\n5. `Enter` to select/deselect\r\n6. `Escape` to close (selections save automatically)\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. `VO+Shift+Up` to stop interacting with the text area\r\n2. `VO+U` → Headings to find the \"Labels\" heading in the sidebar\r\n3. `VO+Space` on the Labels gear/button to open the dropdown\r\n4. `VO+Down` or arrow keys to navigate labels\r\n5. `VO+Space` to select/deselect\r\n6. `Escape` to close (selections save automatically)\r\n\r\n
\r\n\r\n### Submitting the issue\r\n\r\n1. Tab to \"Submit new issue\" button\r\n2. Press `Enter`\r\n\r\n
\r\nGitHub CLI (gh) alternative - filing a new issue\r\n\r\nCreate an issue from your terminal:\r\n\r\n```bash\r\n# Interactive: prompts for title, body, labels, and assignees\r\ngh issue create\r\n\r\n# Inline: provide everything on the command line\r\ngh issue create --title \"Screen reader announces wrong count on Issues list\" \\\r\n --body \"## What happened\\n\\nThe count says 14 but only 12 issues are visible.\" \\\r\n --label \"bug,accessibility\" \\\r\n --assignee @me\r\n\r\n# Use a template (if the repo has issue templates)\r\ngh issue create --template \"bug_report.md\"\r\n```\r\n\r\nThe interactive mode walks you step-by-step through title, body (opens your editor), labels, and assignees - fully usable from a terminal with a screen reader.\r\n\r\n
\r\n\r\n### Learning Cards: Filing a New Issue\r\n\r\n
\r\nScreen reader users\r\n\r\n- After pressing \"New issue,\" if a template picker appears, press `3` to jump between template names; each has a \"Get started\" link next to it\r\n- In the title field, type at least 12 characters for a meaningful title; press `Tab` to move to the body field\r\n- Press `Ctrl+Enter` from inside the body text area to submit the issue without needing to find the Submit button\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- The green \"New issue\" button is in the top-right of the Issues list page; at 200%+ zoom it may wrap below the search bar\r\n- Template cards (if the repo uses them) show truncated descriptions at high zoom; hover over them for the full text\r\n- The sidebar dropdowns for Labels, Assignees, and Milestone are gear icons that may be small at high zoom; they open searchable dropdown panels\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- The new issue form has a Title field at the top and a large Body text area below; a formatting toolbar (bold, italic, code, etc.) appears above the body\r\n- The Write/Preview tabs above the body let you toggle between editing and rendered Markdown views\r\n- Sidebar options (Labels, Assignees, Milestone) appear to the right of the body field; click the gear icon next to each to open a dropdown\r\n\r\n
\r\n\r\n### Tool Cards: File a New Issue\r\n\r\n**github.com (browser):**\r\n1. Navigate to the repository's **Issues** tab (or press `G` then `I`).\r\n2. Click **New issue**, choose a template or blank issue.\r\n3. Fill in the title and description, then click **Submit new issue**.\r\n\r\n**github.dev (web editor):**\r\nNot available -- issues are managed through the repository's Issues tab, not the code editor.\r\n\r\n**VS Code Desktop (GitHub Pull Requests extension):**\r\n1. Open the **GitHub** panel in the sidebar.\r\n2. Under **Issues**, click the **+** icon to create a new issue.\r\n3. Fill in the title and body, then click **Create**.\r\n\r\n**GitHub Desktop:**\r\nNot directly supported. Click **Repository > View on GitHub** to open the browser, then file the issue there.\r\n\r\n**Git CLI / GitHub CLI:**\r\n```bash\r\ngh issue create --title \"Your title\" --body \"Description here\"\r\n# Or interactively:\r\ngh issue create\r\n```\r\n\r\n\r\n## Cross-Referencing Issues\r\n\r\nLinking issues and PRs to each other creates a trail of context that helps everyone understand the project's history.\r\n\r\n### Closing keywords in PR descriptions or issue comments\r\n\r\nWhen you type these phrases in a PR description or comment (followed by an issue number), GitHub creates a connection:\r\n\r\n| Keyword | Effect on merge |\r\n| --------- | ---------------- |\r\n| `Closes #42` | Closes issue #42 when the PR merges |\r\n| `Fixes #42` | Same - typically for bugs |\r\n| `Resolves #42` | Same - general use |\r\n| `refs #42` | Creates a reference without auto-closing |\r\n| `cc @username` | Notifies the person |\r\n\r\n### Mentioning another issue in a comment\r\n\r\nSimply type `#` followed by a number anywhere in a comment body. GitHub autocompletes with a dropdown of matching issues and PRs:\r\n\r\n```text\r\nStep 1: Type # in the comment box (Focus Mode)\r\nStep 2: A dropdown appears with issues and PRs\r\nStep 3: ↑/↓ to navigate, or type more numbers to filter\r\nStep 4: Enter to insert the reference\r\n```\r\n\r\n### Cross-repo references\r\n\r\n`owner/repo#42` - references issue #42 in a different repository.\r\n\r\n### Learning Cards: Cross-Referencing Issues\r\n\r\n**Screen reader users:**\r\n- Type `#` in any comment body to trigger GitHub's autocomplete dropdown; press `Down Arrow` to browse matching issues and `Enter` to insert the reference link\r\n- Use `Closes #42` (not just `#42`) in PR descriptions so GitHub automatically closes the issue on merge; your screen reader will confirm the link is created in the PR timeline\r\n- Cross-references appear as timeline events on the linked issue; navigate with `H` to find \"mentioned this issue\" entries to trace the conversation history\r\n\r\n**Low-vision users:**\r\n- Cross-reference links (`#42`) render as colored, clickable links in both issue bodies and PR descriptions; at high zoom they remain inline with surrounding text\r\n- The autocomplete dropdown triggered by `#` may overlap content at high magnification; type additional digits to narrow results and reduce dropdown size\r\n- Back-links appear automatically on the referenced issue's timeline, so you can verify the connection was created by visiting either side\r\n\r\n**Sighted users:**\r\n- Use `Closes #42`, `Fixes #42`, or `Resolves #42` in PR descriptions for auto-closing on merge; `refs #42` creates a reference without auto-close, useful for \"related but not solved\" links\r\n- GitHub's autocomplete (`#` then type) searches both issue titles and numbers, so you can find issues by keyword without memorizing numbers\r\n- Cross-repo references use the format `owner/repo#42` -- useful when your PR in one repository fixes a bug tracked in another\r\n\r\n\r\n## Sub-Issues - Parent and Child Relationships\r\n\r\n**Sub-issues** (released 2025) let you nest issues inside a parent issue to break large work into tracked pieces. A \"parent\" issue contains a list of child issues; each child is a full issue with its own discussion, labels, and assignees.\r\n\r\n### When to Use Sub-Issues\r\n\r\n| Use case | Example |\r\n| ---------- | --------- |\r\n| Large feature broken down | Parent: \"Redesign navigation\"; Children: \"Keyboard nav,\" \"Screen reader nav,\" \"Mobile nav\" |\r\n| Epic tracking | Parent: \"WCAG 2.1 AA compliance\"; Children: one issue per failing criterion |\r\n| Release milestone | Parent: \"v2.0 release\"; Children: every required PR/fix |\r\n\r\n### Creating a Sub-Issue\r\n\r\nFrom any open issue:\r\n\r\n```text\r\n1. Open the parent issue page\r\n2. Scroll to (or H-navigate to) the \"Sub-issues\" section in the issue body/sidebar\r\n3. Tab to \"Add sub-issue\" button → Enter\r\n4. Type the issue number or title to search\r\n5. Select the issue from the dropdown → Enter to link\r\n Or: select \"Create new issue\" to create and link in one step\r\n```\r\n\r\n**Screen reader note:** The sub-issues section is announced as a region. After linking, the child issue appears as a list item with a checkbox showing its open/closed state. Tab through to read each child's title and status.\r\n\r\n### Reading Sub-Issues on a Parent Issue\r\n\r\n```text\r\nH → \"Sub-issues\" heading\r\n↓ → list of linked child issues\r\nEach item: [checkbox state] [issue title] [#number] [open/closed badge]\r\nTab → \"Add sub-issue\" button (if you have write access)\r\n```\r\n\r\n**Progress indicator:** The parent issue shows a completion bar (e.g., \"3 of 7 completed\") based on how many child issues are closed. Screen readers announce this as a progress region.\r\n\r\n### Viewing a Child Issue's Parent\r\n\r\nEvery child issue shows a \"Parent issue\" link near the top of the page (above the description). Navigate with `H` or links (`K`) to find it.\r\n\r\n### Sub-Issues vs. Task Lists\r\n\r\n| Feature | Task list checkboxes | Sub-issues |\r\n| --------- | --------------------- | ------------ |\r\n| Location | Issue description (Markdown) | Sidebar/section (structured data) |\r\n| Each item is | Text line + checkbox | A full GitHub issue |\r\n| Tracked in Projects | No (checkbox only) | Yes (each child tracks independently) |\r\n| Cross-repo | No | Yes |\r\n| Best for | Quick checklists in one issue | Multi-issue work tracking |\r\n\r\n> **Workshop tip:** If you are working on a feature that requires multiple PRs or involves several team members, ask the maintainer to create a parent issue. You can then claim individual child issues without one person owning the whole feature.\r\n\r\n### Learning Cards: Sub-Issues\r\n\r\n**Screen reader users:**\r\n- The sub-issues section is announced as a region; press `H` to navigate to the \"Sub-issues\" heading, then arrow down through the list where each child announces its checkbox state, title, and open/closed badge\r\n- The parent issue shows a progress indicator (\"3 of 7 completed\") announced as a progress region; listen for this after the sub-issues heading to gauge overall status\r\n- Every child issue includes a \"Parent issue\" link near the top of its page; navigate with `K` (links) to find it and jump back to the parent quickly\r\n\r\n**Low-vision users:**\r\n- The completion progress bar on the parent issue uses color to show progress; in high-contrast mode, completed vs. remaining segments use distinct system colors\r\n- At high zoom, the \"Add sub-issue\" button may wrap below the sub-issues list; Tab past the last child item to reach it\r\n- Each child issue's open/closed badge uses both color and text (\"Open\" or \"Closed\"), so status is readable without relying on color alone\r\n\r\n**Sighted users:**\r\n- Sub-issues appear as a checklist with a progress bar on the parent issue; each child links directly to its own issue page with full discussion and labels\r\n- Use sub-issues instead of Markdown task-list checkboxes when each item needs its own assignee, labels, or cross-repo tracking -- sub-issues are structured data, not just text\r\n- Creating a sub-issue from the parent's \"Add sub-issue\" button auto-links the new issue; you can also link existing issues by searching their number or title\r\n\r\n\r\n## Managing Issues (for Maintainers and Triagers)\r\n\r\n### Closing an issue\r\n\r\n
\r\nVisual / mouse users\r\n\r\nScroll to the bottom of the issue page. Click the **Close issue** button next to the comment box. Optionally type a closing comment first. If you want to record a reason, click the dropdown arrow on the button and choose **Close as completed** or **Close as not planned**.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. **Keyboard shortcut (fastest):** Navigate to the comment text area (`D` → \"Add a comment\" landmark), switch to Focus Mode, then press `Ctrl+Shift+Enter` to close the issue\r\n2. **Button approach:** `Tab` to the \"Close issue\" button (at the bottom of the page, near the comment box) and press `Enter`\r\n3. Optionally leave a closing comment first\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. **Keyboard shortcut (fastest):** `VO+U` → Landmarks → \"Add a comment\", interact with the text area (`VO+Shift+Down`), then press `Cmd+Shift+Return` to close the issue\r\n2. **Button approach:** Quick Nav `B` or `Tab` to find the \"Close issue\" button, then `VO+Space`\r\n3. Optionally leave a closing comment first\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative - closing and reopening\r\n\r\nClose or reopen an issue from your terminal:\r\n\r\n```bash\r\n# Close an issue\r\ngh issue close 42\r\n\r\n# Close with a reason\r\ngh issue close 42 --reason \"completed\"\r\ngh issue close 42 --reason \"not planned\"\r\n\r\n# Close with a comment\r\ngh issue close 42 --comment \"Fixed in PR #45.\"\r\n\r\n# Reopen a closed issue\r\ngh issue reopen 42\r\n```\r\n\r\n
\r\n\r\n### Reopening a closed issue\r\n\r\nIf an issue is Closed, the \"Close issue\" button becomes \"Reopen issue\" - navigate and activate to reopen.\r\n\r\n### Assigning an issue\r\n\r\nFrom the issue sidebar:\r\n\r\n1. Navigate to \"Assignees\" heading (`3` or `H`)\r\n2. Activate the gear/plus button\r\n3. Type a username in the search field\r\n4. Select from the dropdown\r\n\r\n
\r\nGitHub CLI (gh) alternative - assigning and labeling\r\n\r\nManage assignments and labels from your terminal:\r\n\r\n```bash\r\n# Assign yourself\r\ngh issue edit 42 --add-assignee @me\r\n\r\n# Add labels\r\ngh issue edit 42 --add-label \"accessibility,in progress\"\r\n\r\n# Remove a label\r\ngh issue edit 42 --remove-label \"needs triage\"\r\n\r\n# Set a milestone\r\ngh issue edit 42 --milestone \"Hackathon Day 1\"\r\n```\r\n\r\n
\r\n\r\n### Changing labels\r\n\r\nFrom the issue sidebar:\r\n\r\n1. Navigate to \"Labels\" heading\r\n2. Activate the gear button\r\n3. Select/deselect labels from the dropdown\r\n4. Press Escape to save\r\n\r\n### Transferring or deleting an issue\r\n\r\nAvailable from the \"...\" (ellipsis) button at the top of the issue - navigate buttons with `B` to find it.\r\n\r\n### Learning Cards: Managing Issues\r\n\r\n**Screen reader users:**\r\n- Close an issue instantly with `Ctrl+Shift+Enter` from the comment text area (Focus Mode) -- no need to Tab to the Close button\r\n- The sidebar sections (Assignees, Labels, Milestone) each have their own heading; press `H` or `3` to jump between them, then activate the gear icon to open each dropdown\r\n- Use `gh issue edit 42 --add-label \"accessibility\" --add-assignee @me` to batch-update labels and assignments from the terminal without navigating sidebar controls\r\n\r\n**Low-vision users:**\r\n- Sidebar controls (Assignees, Labels, Milestone) are narrow at default width; at high zoom they stack vertically and each dropdown opens a searchable overlay that is easier to read\r\n- The Close issue button turns green and its label changes to \"Reopen issue\" once closed; in high-contrast mode, both states use distinct system colors\r\n- Type in the search field inside each sidebar dropdown (Labels, Assignees) to filter long lists rather than scrolling through all options at high magnification\r\n\r\n**Sighted users:**\r\n- The issue sidebar on the right contains Assignees, Labels, Projects, and Milestone in collapsible sections; click the gear icon next to each to open the edit dropdown\r\n- Use the dropdown arrow on the Close button to choose \"Close as completed\" vs. \"Close as not planned\" -- this distinction helps with project tracking and search filtering\r\n- The \"...\" menu at the top of any issue provides Transfer, Pin, Lock, and Delete options for repository maintainers\r\n\r\n\r\n## The \"good first issue\" Label - Your Entry Point\r\n\r\nWhen looking for your first open source contribution:\r\n\r\n1. Navigate to any project's Issues tab\r\n2. Filter by label: type `is:open label:\"good first issue\"` in the search\r\n3. Read through issues until you find one in your area of interest\r\n4. Comment on the issue: \"Hi, I'd like to work on this. Can I be assigned?\"\r\n5. Wait for a maintainer to respond and assign you before starting work\r\n\r\n**Remember:** It's respectful to ask before starting. Maintainers juggle many discussions and need to know who is working on what to avoid duplicated effort.\r\n\r\n### Learning Cards: The \"good first issue\" Label\r\n\r\n**Screen reader users:**\r\n- Use the filter query `is:open label:\"good first issue\"` in the search bar to jump directly to beginner-friendly issues; `gh issue list --label \"good first issue\"` does the same in the terminal\r\n- Before claiming an issue, read existing comments to check whether someone else has already been assigned; listen for \"assigned to\" in the sidebar metadata\r\n- When you comment to claim an issue, include a sentence about your approach so the maintainer can give early feedback before you start coding\r\n\r\n**Low-vision users:**\r\n- The \"good first issue\" label renders with a distinct background color (typically light purple or teal); in high-contrast mode it uses system highlight colors with readable text\r\n- Filter results may include issues with multiple labels stacked together; at high zoom, labels wrap to a second line but remain readable\r\n- Bookmark the filtered URL (`/issues?q=is:open+label:\"good first issue\"`) in your browser for one-click access to beginner issues across your favorite repositories\r\n\r\n**Sighted users:**\r\n- The \"good first issue\" label is a GitHub convention recognized across the ecosystem; many projects also use \"help wanted\" for intermediate tasks\r\n- Always comment before starting work -- even if unassigned -- to avoid duplicating effort with another contributor who may already be working quietly\r\n- Read the issue's linked PR history (if any) to see whether previous attempts were made and why they were closed; this saves you from repeating known dead ends\r\n\r\n\r\n## Accessibility-Specific Issue Writing Tips\r\n\r\nWhen filing accessibility bugs, these details help maintainers reproduce and fix the problem:\r\n\r\n1. **Screen reader and version** - \"NVDA 2025.3.3\" not just \"screen reader\"\r\n2. **OS and version** - \"Windows 11 22H2\"\r\n3. **Browser and version** - \"Chrome 124.0.6367.82\"\r\n4. **GitHub interface** - \"Modern experience (default since Jan 2026)\" or \"Classic experience (opted out)\"\r\n5. **What was announced** - quote the exact text your screen reader spoke\r\n6. **What should have been announced** - describe the expected behavior\r\n7. **ARIA issue if known** - e.g., \"The button has no accessible name\"\r\n8. **Steps to reproduce** - numbered, step-by-step\r\n9. **Frequency** - \"This happens every time\" vs \"intermittent\"\r\n\r\n### Example of a well-filed accessibility issue\r\n\r\n```text\r\nTitle: Issues list does not announce label filtering results to screen readers\r\n\r\n## What happened\r\nWhen I apply a label filter on the Issues list using the Labels dropdown,\r\nthe filtered list updates visually but NVDA does not announce that the\r\nresults changed or how many items are now shown.\r\n\r\n## What I expected\r\nAfter filtering, the screen reader should announce something like\r\n\"14 issues open, filtered by label: accessibility\" or a live region\r\nupdate indicating the results changed.\r\n\r\n## How to reproduce\r\n1. Navigate to any repo's Issues tab\r\n2. Press B to navigate to the \"Label\" filter button\r\n3. Press Enter to open the dropdown\r\n4. Select the \"accessibility\" label\r\n5. Press Escape to close\r\n6. Notice: no announcement that filtering has been applied\r\n\r\n## Environment\r\n- Screen reader: NVDA 2025.3.3 (with NVDA+Chrome)\r\n- Browser: Chrome 124.0.6367.82\r\n- OS: Windows 11 22H2\r\n- GitHub interface: Modern experience (default since Jan 2026)\r\n\r\n## Additional context\r\nJAWS 2026 also does not announce. VoiceOver on macOS Sonoma with\r\nSafari 17 does announce \"List updated\" when filtering is applied,\r\nso the macOS behavior appears correct.\r\n```\r\n\r\n### Learning Cards: Accessibility-Specific Issue Writing\r\n\r\n**Screen reader users:**\r\n- Always quote the exact text your screen reader announced in the issue body; wrap it in a fenced code block so readers know it is literal output, not your description\r\n- Include your screen reader name and version (e.g., \"NVDA 2025.3.3\") plus browser and OS; this lets maintainers reproduce with the same toolchain\r\n- Test with a second screen reader or browser if possible and note the results -- \"Also fails in JAWS 2026 with Chrome; works in VoiceOver with Safari\" dramatically narrows the debugging scope\r\n\r\n**Low-vision users:**\r\n- When filing zoom or contrast bugs, state your exact zoom level and whether you use Windows High Contrast, macOS Increase Contrast, or a browser extension\r\n- Screenshots are powerful evidence; annotate them (circle the problem area, add a text callout) and always include alt text describing what the screenshot shows\r\n- Note whether the issue occurs only at certain zoom levels or viewport widths; a bug at 400% that disappears at 200% points to a CSS breakpoint problem\r\n\r\n**Sighted users:**\r\n- Even if you do not use assistive technology, you can file accessibility issues by testing with keyboard-only navigation (Tab, Enter, Escape) and noting where focus is lost or trapped\r\n- Include the ARIA role or attribute involved if you can identify it from browser DevTools (e.g., \"The button has `role=presentation` and no accessible name\")\r\n- Link to the relevant WCAG success criterion when possible (e.g., \"Fails WCAG 2.1 SC 1.3.1 Info and Relationships\"); this gives maintainers a clear standard to design against\r\n\r\n\r\n## Writing Effective Issues\r\n\r\n> **See also:** [Appendix N: Advanced Search](appendix-n-advanced-search.md) covers search qualifiers to find existing issues before filing a new one.\r\n\r\nA well-written issue saves everyone time -- the maintainer who reads it, the contributor who fixes it, and the future searcher who finds it six months later. This section gives you reusable templates for the two most common issue types and a set of principles that apply to every issue you file.\r\n\r\n### Bug Report Structure\r\n\r\nA strong bug report answers five questions. Use this template every time you report something broken.\r\n\r\n| Section | What to write |\r\n|---|---|\r\n| **Title** | Follow the formula: \"When I [action], [unexpected result] instead of [expected result]\" |\r\n| **Steps to Reproduce** | Numbered list -- start from the earliest relevant step |\r\n| **Expected Behavior** | What *should* happen according to documentation or common sense |\r\n| **Actual Behavior** | What *does* happen -- include exact error messages or screenshots |\r\n| **Environment** | OS, browser, screen reader, app version -- anything that might matter |\r\n\r\nThe title formula is the most important part. A title like \"When I press Enter on the Submit button, nothing happens instead of creating the issue\" tells the maintainer exactly what is broken before they even open the issue.\r\n\r\n> **Screen reader tip:** When pasting error messages into the Actual Behavior section, wrap them in a fenced code block (triple backticks). Screen readers will announce \"code block\" so the listener knows the text is a literal error, not your description.\r\n\r\n**Steps to Reproduce matter more than you think.** Maintainers cannot fix what they cannot recreate. Number every step, starting from a clean slate -- \"Open the repository\" is better than \"Go to the page.\" Include what you clicked, what keyboard shortcut you pressed, and what happened after each step.\r\n\r\n### Feature Request Structure\r\n\r\nFeature requests work best when they focus on the *problem* before jumping to the solution. Use this four-part structure:\r\n\r\n1. **Problem statement** -- Describe the pain point. What are you trying to do, and why is it hard or impossible right now?\r\n2. **Proposed solution** -- Your best idea for fixing the problem. Be specific enough to discuss, but hold it loosely.\r\n3. **Alternatives considered** -- Other approaches you thought about and why they fell short. This shows you have done your homework.\r\n4. **Who benefits** -- Name the audience. \"Screen reader users navigating large repositories\" is more compelling than \"everyone.\"\r\n\r\nA feature request that starts with \"I want a dark mode toggle\" is weaker than one that starts with \"Low-vision users report eyestrain after 20 minutes because the current theme has insufficient contrast.\" The second version gives maintainers something to design around.\r\n\r\n### General Issue Writing Principles\r\n\r\nThese rules apply to every issue -- bugs, features, questions, and everything in between.\r\n\r\n**One issue per problem.** If you discovered two bugs during the same session, file two separate issues. Combining them makes it impossible to close one without the other and clutters the conversation.\r\n\r\n**Write searchable titles.** Future contributors will search before filing. \"Bug with button\" will never surface in a search for \"Submit button unresponsive on Safari.\" Front-load the title with the specific component or action.\r\n\r\n**Include context, not assumptions.** Instead of \"The API is broken,\" write \"The `/repos` endpoint returns a 403 when I pass a valid token.\" Let maintainers draw their own conclusions from the evidence you provide.\r\n\r\n**Link related issues.** If your bug might be connected to issue #42, mention it: \"This might be related to #42.\" GitHub automatically creates a back-link, building a web of context that helps everyone. You will learn more about cross-referencing in [Chapter 6](06-working-with-pull-requests.md).\r\n\r\n| Principle | Bad example | Good example |\r\n|---|---|---|\r\n| One issue per problem | \"The button is broken and also the logo is wrong\" | Two separate issues, each with its own title |\r\n| Searchable title | \"Help needed\" | \"Keyboard focus lost after closing modal dialog\" |\r\n| Context over assumptions | \"Nothing works\" | \"After upgrading to v2.3, the dashboard returns a blank page on Firefox 124\" |\r\n| Link related issues | (no mention) | \"Possibly related to #42 -- same component, different trigger\" |\r\n\r\n### Before and After: A Vague Issue vs. a Clear Issue\r\n\r\n**Vague issue (hard to act on):**\r\n\r\n> **Title:** Bug\r\n>\r\n> It doesn't work. I tried clicking and nothing happened. Please fix.\r\n\r\nThe maintainer has to ask: What doesn't work? Where did you click? What browser? What did you expect? Every follow-up question costs a round-trip of waiting.\r\n\r\n**Clear issue (ready to fix):**\r\n\r\n> **Title:** When I press Enter on the \"New issue\" button, nothing happens instead of opening the issue form\r\n>\r\n> **Steps to Reproduce:**\r\n> 1. Navigate to github.com/org/repo\r\n> 2. Press `G` then `I` to go to the Issues tab\r\n> 3. Tab to the \"New issue\" button\r\n> 4. Press `Enter`\r\n>\r\n> **Expected:** The new issue form opens.\r\n>\r\n> **Actual:** The page does not respond. No error in the console.\r\n>\r\n> **Environment:** Windows 11, Firefox 128, JAWS 2025\r\n\r\nThe maintainer can reproduce this in under a minute. No follow-up questions needed -- the fix can start immediately.\r\n\r\n> **Screen reader tip:** You can use the issue template feature in GitHub to pre-fill these sections automatically. If the repository provides templates, your screen reader will announce each section heading as you Tab through the form. You will set up your own issue templates in [Chapter 17](17-issue-templates.md).\r\n\r\n### Learning Cards: Writing Effective Issues\r\n\r\n
\r\nScreen reader users\r\n\r\n- Use fenced code blocks (triple backticks) when pasting error messages or screen reader output; your screen reader announces \"code block\" so listeners know the text is literal, not description\r\n- When writing \"Steps to Reproduce,\" type each step as a numbered Markdown list item (`1.`, `2.`, etc.) so screen readers announce \"list with N items\"\r\n- Type `#` in the comment body to trigger issue autocomplete; press `Down Arrow` to navigate matching issues and `Enter` to insert a cross-reference link\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- Use the Preview tab (next to Write) to check your Markdown rendering before submitting; headings, bold text, and code blocks are much easier to proofread in rendered form\r\n- Screenshots with alt text are valuable evidence; add them with the image button in the formatting toolbar or drag-and-drop into the body field\r\n- Keep paragraphs short (3-4 sentences max) so the issue is scannable at high zoom without excessive scrolling\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- A well-structured issue uses H2 headings (##) for major sections: What happened, Expected, How to reproduce, Environment\r\n- GitHub renders Markdown tables in issue bodies; use a table to compare expected vs. actual behavior side by side\r\n- The title appears in issue lists, email notifications, and search results; front-load it with the specific component or action for discoverability\r\n\r\n
\r\n\r\n\r\n## Try It: File Your First Issue\r\n\r\n**Time:** 3 minutes | **What you need:** Browser, signed in to GitHub\r\n\r\nGo to the Learning Room repository and file a real issue:\r\n\r\n1. Navigate to the Issues tab (press `G` then `I` in Focus Mode)\r\n2. Find and activate the \"New issue\" button (`K` to links, or `Tab` to it)\r\n3. In the title field, type: **\"Introduce myself - [Your Name]\"**\r\n4. In the description, write 2-3 sentences: who you are, what screen reader you use, and one thing you're hoping to learn today\r\n5. Press `Ctrl+Enter` to submit (or Tab to the Submit button and press `Enter`)\r\n\r\n**You're done.** You just filed your first GitHub issue. Go read someone else's introduction and leave a friendly comment - press `3` to jump between issue titles on the Issues list.\r\n\r\n> **What success feels like:** Your issue is live. Other participants can see it. You just contributed to a real repository - and it took less than three minutes.\r\n\r\n### Learning Cards: Filing Your First Issue\r\n\r\n**Screen reader users:**\r\n- After pressing `Ctrl+Enter` to submit, listen for the page reload; GitHub navigates to your new issue page where the title is the first heading -- press `1` to confirm it matches what you typed\r\n- Navigate the issue list with `3` (heading level 3) to jump between issue titles; this is faster than arrowing through every element on the page\r\n- If the template picker appears, use `Tab` and `Enter` to select \"Open a blank issue\"; template names are announced as link text\r\n\r\n**Low-vision users:**\r\n- The \"New issue\" button is prominent and green on the Issues list page; at high zoom it remains visible near the top of the page and does not collapse into a menu\r\n- The title field is full-width and the body field expands as you type; both are easy to locate and target at any zoom level\r\n- After submitting, your new issue page shows your avatar, title, and description in high-contrast-friendly layout; verify the content rendered correctly before moving on\r\n\r\n**Sighted users:**\r\n- Your issue immediately appears at the top of the Issues list; the green \"Open\" badge confirms it was created successfully\r\n- Read a few other students' introduction issues and leave a comment to practice the commenting workflow from the Leaving a Comment section\r\n- Notice how the issue number (e.g., #150) is auto-assigned and appears in the URL and page title; you will use this number for cross-references later\r\n\r\n\r\n> ### Day 2 Amplifier - Accessibility Agents: `@issue-tracker`\r\n>\r\n> **File, read, comment on, and triage real issues manually before using any agent.** If you have not done the triage work yourself - reading descriptions, assigning labels, identifying duplicates - you cannot evaluate whether an agent's priority scoring is correct. The skill must exist before the amplifier is useful.\r\n>\r\n> Once you have mastered manual issue management:\r\n>\r\n> - **In VS Code** - `@issue-tracker find open issues labeled good-first-issue` searches cross-repository with community sentiment scoring, release-awareness prioritization, and batch-reply capability across every repo you have access to\r\n> - **In your repo** - The issue templates in `accessibility-agents/.github/ISSUE_TEMPLATE/` structure both human filing and automated triage; fork [accessibility-agents](https://github.com/Community-Access/accessibility-agents) and that structure travels into any project you lead\r\n> - **In the cloud** - GitHub Agentic Workflows triage new issues the moment they are opened: applying labels, posting first-response comments, adding to Project boards - the same triage actions you practiced manually today, running at scale\r\n>\r\n> *Today you are the triage engine. On Day 2, you understand the engine well enough to direct it.*\r\n\r\n\r\n> **Challenge Time:** It's time for the real deal. Go to the [Challenge Hub](CHALLENGES.md) and complete **Challenge 2: File Your First Issue** and **Challenge 3: Join the Conversation**. When Aria the bot replies to you, she will tell you when it's time to move to [Chapter 06: Working with Pull Requests](06-working-with-pull-requests.md).\r\n\r\n---\r\n\r\n\r\n*Next: [Chapter 06: Working with Pull Requests](06-working-with-pull-requests.md)* \r\n*Back: [Chapter 04: The Learning Room](04-the-learning-room.md)* \r\n*Related appendices: [Appendix N: Advanced Search](appendix-n-advanced-search.md) | [Appendix V: GitHub Mobile](appendix-v-github-mobile.md)*\r\n\r\n\r\n\r\n\r\n" + } + ] +} diff --git a/podcasts/logs/agentic-pilots/chapter-plan-audit.json b/podcasts/logs/agentic-pilots/chapter-plan-audit.json new file mode 100644 index 0000000..1f85160 --- /dev/null +++ b/podcasts/logs/agentic-pilots/chapter-plan-audit.json @@ -0,0 +1,9294 @@ +{ + "generatedAt": "2026-05-13T01:55:02.424Z", + "plansAudited": 75, + "weakTitles": 0, + "genericTitles": 0, + "worstOffenders": [], + "reports": [ + { + "slug": "ep00-welcome", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep00-welcome-chapters.json", + "chapterCount": 23, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Welcome to Git Going with GitHub: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "GitHub Learning Room - Your Complete Workshop Companion", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "How This Course Works", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "Before You Begin", + "startSegmentIndex": 21, + "score": "strong" + }, + { + "index": 5, + "title": "Companion Audio Series", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 6, + "title": "Day 1: GitHub Foundations", + "startSegmentIndex": 28, + "score": "strong" + }, + { + "index": 7, + "title": "Day 2: VS Code + Accessibility Agents", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 8, + "title": "Appendices - Reference Material", + "startSegmentIndex": 32, + "score": "strong" + }, + { + "index": 9, + "title": "Exercises at a Glance", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 10, + "title": "Getting Help", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 11, + "title": "Workshop at a Glance", + "startSegmentIndex": 40, + "score": "strong" + }, + { + "index": 12, + "title": "What This Guide Does", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 13, + "title": "When Tools or Pages Change", + "startSegmentIndex": 45, + "score": "strong" + }, + { + "index": 14, + "title": "Step 1 - Know Your Starting Place", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 15, + "title": "Step 2 - Accept the GitHub Classroom Assignment", + "startSegmentIndex": 52, + "score": "strong" + }, + { + "index": 16, + "title": "Step 3 - Understand the Learning Room", + "startSegmentIndex": 60, + "score": "strong" + }, + { + "index": 17, + "title": "Step 4 - Find Challenge 1", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 18, + "title": "Step 5 - Choose the Tool That Fits the Moment", + "startSegmentIndex": 68, + "score": "strong" + }, + { + "index": 19, + "title": "Step 6 - What to Listen For with a Screen Reader", + "startSegmentIndex": 72, + "score": "strong" + }, + { + "index": 20, + "title": "Step 7 - Use the Support Built into the Course", + "startSegmentIndex": 74, + "score": "strong" + }, + { + "index": 21, + "title": "Step 8 - Your First Success Check", + "startSegmentIndex": 79, + "score": "strong" + }, + { + "index": 22, + "title": "Where to Go Next", + "startSegmentIndex": 83, + "score": "strong" + }, + { + "index": 23, + "title": "Welcome to Git Going with GitHub: Wrap-Up", + "startSegmentIndex": 89, + "score": "strong" + } + ] + }, + { + "slug": "ep01-pre-workshop-setup", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep01-pre-workshop-setup-chapters.json", + "chapterCount": 12, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Pre-Workshop Setup: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Everything You Need Before Day 1 Begins", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Step 1 - Create Your GitHub Account", + "startSegmentIndex": 22, + "score": "strong" + }, + { + "index": 4, + "title": "Step 2 - Configure GitHub Accessibility Settings", + "startSegmentIndex": 56, + "score": "strong" + }, + { + "index": 5, + "title": "Step 3 - Configure Your Profile", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 6, + "title": "Step 4 - Check GitHub Feature Preview Settings", + "startSegmentIndex": 102, + "score": "strong" + }, + { + "index": 7, + "title": "Step 6 - Install Git and Visual Studio Code", + "startSegmentIndex": 159, + "score": "strong" + }, + { + "index": 8, + "title": "Step 7 - Configure Git Identity", + "startSegmentIndex": 200, + "score": "strong" + }, + { + "index": 9, + "title": "Step 8 - Install VS Code Extensions", + "startSegmentIndex": 218, + "score": "strong" + }, + { + "index": 10, + "title": "Other GitHub Access Methods (Reference Only)", + "startSegmentIndex": 253, + "score": "strong" + }, + { + "index": 11, + "title": "Getting Help Before the Event", + "startSegmentIndex": 268, + "score": "strong" + }, + { + "index": 12, + "title": "Pre-Workshop Setup: Wrap-Up", + "startSegmentIndex": 272, + "score": "strong" + } + ] + }, + { + "slug": "ep02-github-web-structure", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep02-github-web-structure-chapters.json", + "chapterCount": 14, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Understanding GitHub on the Web: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "How GitHub Is Organized, and How to Orient Yourself on Every.", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. GitHub's Three-Level Structure", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "2. What Is Always on Every GitHub Page", + "startSegmentIndex": 10, + "score": "strong" + }, + { + "index": 5, + "title": "3. How to Tell Where You Are", + "startSegmentIndex": 21, + "score": "strong" + }, + { + "index": 6, + "title": "5. Visual Map of a Repository Page", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 7, + "title": "6. Screen Reader Orientation Sequence", + "startSegmentIndex": 71, + "score": "strong" + }, + { + "index": 8, + "title": "7. Landmark Structure by Page Type", + "startSegmentIndex": 81, + "score": "strong" + }, + { + "index": 9, + "title": "8. GitHub's Heading Hierarchy in Practice", + "startSegmentIndex": 84, + "score": "strong" + }, + { + "index": 10, + "title": "9. How GitHub's Layout Changes by Viewport", + "startSegmentIndex": 91, + "score": "strong" + }, + { + "index": 11, + "title": "10. The Mental Model - Building Your Internal Map", + "startSegmentIndex": 103, + "score": "strong" + }, + { + "index": 12, + "title": "The 60-Second Orientation", + "startSegmentIndex": 110, + "score": "strong" + }, + { + "index": 13, + "title": "Day 2 Amplifier", + "startSegmentIndex": 115, + "score": "strong" + }, + { + "index": 14, + "title": "Understanding GitHub on the Web: Wrap-Up", + "startSegmentIndex": 118, + "score": "strong" + } + ] + }, + { + "slug": "ep03-navigating-repositories", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep03-navigating-repositories-chapters.json", + "chapterCount": 19, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Navigating Repositories: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "A Screen Reader Guide to GitHub Repositories", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "What Is a Repository Page?", + "startSegmentIndex": 18, + "score": "strong" + }, + { + "index": 4, + "title": "Landing on a Repository - What to Expect", + "startSegmentIndex": 22, + "score": "strong" + }, + { + "index": 5, + "title": "Navigating the Repository Tabs", + "startSegmentIndex": 30, + "score": "strong" + }, + { + "index": 6, + "title": "The Files Table", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 7, + "title": "The Branch Selector", + "startSegmentIndex": 54, + "score": "strong" + }, + { + "index": 8, + "title": "Cloning a Repository", + "startSegmentIndex": 72, + "score": "strong" + }, + { + "index": 9, + "title": "Or with standard Git", + "startSegmentIndex": 79, + "score": "strong" + }, + { + "index": 10, + "title": "Fork vs. Clone vs. Branch - What Is the Difference?", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 11, + "title": "Watching, Starring, and Forking", + "startSegmentIndex": 98, + "score": "strong" + }, + { + "index": 12, + "title": "Viewing a Single File", + "startSegmentIndex": 117, + "score": "strong" + }, + { + "index": 13, + "title": "The Blame View", + "startSegmentIndex": 139, + "score": "strong" + }, + { + "index": 14, + "title": "Commit History", + "startSegmentIndex": 146, + "score": "strong" + }, + { + "index": 15, + "title": "Searching for a File", + "startSegmentIndex": 154, + "score": "strong" + }, + { + "index": 16, + "title": "GitHub Shortcuts for Repository Navigation - Spotlight", + "startSegmentIndex": 164, + "score": "strong" + }, + { + "index": 17, + "title": "The Repository About Section", + "startSegmentIndex": 168, + "score": "strong" + }, + { + "index": 18, + "title": "The Five-Tab Tour", + "startSegmentIndex": 188, + "score": "strong" + }, + { + "index": 19, + "title": "Navigating Repositories: Wrap-Up", + "startSegmentIndex": 194, + "score": "strong" + } + ] + }, + { + "slug": "ep04-the-learning-room", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep04-the-learning-room-chapters.json", + "chapterCount": 14, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "The Learning Room: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "What Is the Learning Room?", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why a Per-Student Repo?", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "Step-by-Step: Accept Your Classroom Assignment and Open Your.", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 5, + "title": "Two Tracks That Reinforce Each Other", + "startSegmentIndex": 43, + "score": "strong" + }, + { + "index": 6, + "title": "Your Learning Room Folder Structure", + "startSegmentIndex": 58, + "score": "strong" + }, + { + "index": 7, + "title": "Your Practice Branch", + "startSegmentIndex": 61, + "score": "strong" + }, + { + "index": 8, + "title": "The Practice Files: What You Will Work On", + "startSegmentIndex": 82, + "score": "strong" + }, + { + "index": 9, + "title": "The Learning Automation System", + "startSegmentIndex": 152, + "score": "strong" + }, + { + "index": 10, + "title": "Study Groups (Optional)", + "startSegmentIndex": 162, + "score": "strong" + }, + { + "index": 11, + "title": "Key Differences: Skills Module vs. Your Learning Room", + "startSegmentIndex": 166, + "score": "strong" + }, + { + "index": 12, + "title": "Tips for Reviewing a Peer's PR", + "startSegmentIndex": 169, + "score": "strong" + }, + { + "index": 13, + "title": "Celebration: You're Contributing", + "startSegmentIndex": 210, + "score": "strong" + }, + { + "index": 14, + "title": "The Learning Room: Wrap-Up", + "startSegmentIndex": 213, + "score": "strong" + } + ] + }, + { + "slug": "ep05-working-with-issues", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep05-working-with-issues-chapters.json", + "chapterCount": 11, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Working with Issues: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Issues as Collaboration", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Create Your First Issue", + "startSegmentIndex": 17, + "score": "strong" + }, + { + "index": 4, + "title": "Comment and @Mention", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 5, + "title": "Add a Sub-Issue", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 6, + "title": "Why Issues Matter", + "startSegmentIndex": 48, + "score": "strong" + }, + { + "index": 7, + "title": "Anatomy of a GitHub Issue", + "startSegmentIndex": 61, + "score": "strong" + }, + { + "index": 8, + "title": "Sub-Issue Relationships", + "startSegmentIndex": 191, + "score": "strong" + }, + { + "index": 9, + "title": "Good First Issue", + "startSegmentIndex": 225, + "score": "strong" + }, + { + "index": 10, + "title": "Accessibility Issue Tips", + "startSegmentIndex": 233, + "score": "strong" + }, + { + "index": 11, + "title": "Working with Issues: Wrap-Up", + "startSegmentIndex": 266, + "score": "strong" + } + ] + }, + { + "slug": "ep06-working-with-pull-requests", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep06-working-with-pull-requests-chapters.json", + "chapterCount": 17, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Working with Pull Requests: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Creating, Reviewing, and Merging Pull Requests with a Screen.", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 44, + "score": "strong" + }, + { + "index": 4, + "title": "What Is a Pull Request?", + "startSegmentIndex": 55, + "score": "strong" + }, + { + "index": 5, + "title": "Navigating to Pull Requests", + "startSegmentIndex": 60, + "score": "strong" + }, + { + "index": 6, + "title": "The Pull Request List Page", + "startSegmentIndex": 72, + "score": "strong" + }, + { + "index": 7, + "title": "Navigating the PR Tab Bar", + "startSegmentIndex": 75, + "score": "strong" + }, + { + "index": 8, + "title": "Reading the Checks Tab", + "startSegmentIndex": 105, + "score": "strong" + }, + { + "index": 9, + "title": "Reading the Files Changed Tab", + "startSegmentIndex": 115, + "score": "strong" + }, + { + "index": 10, + "title": "Requesting reviewers", + "startSegmentIndex": 200, + "score": "strong" + }, + { + "index": 11, + "title": "Submitting a Review", + "startSegmentIndex": 205, + "score": "strong" + }, + { + "index": 12, + "title": "Understanding Merge Options (for Maintainers)", + "startSegmentIndex": 251, + "score": "strong" + }, + { + "index": 13, + "title": "After a PR is merged", + "startSegmentIndex": 254, + "score": "strong" + }, + { + "index": 14, + "title": "Auto-Merge - Merging When You Can't Wait Around", + "startSegmentIndex": 256, + "score": "strong" + }, + { + "index": 15, + "title": "Writing PR Descriptions That Get Reviewed", + "startSegmentIndex": 269, + "score": "strong" + }, + { + "index": 16, + "title": "Read a Real Pull Request", + "startSegmentIndex": 286, + "score": "strong" + }, + { + "index": 17, + "title": "Working with Pull Requests: Wrap-Up", + "startSegmentIndex": 292, + "score": "strong" + } + ] + }, + { + "slug": "ep07-merge-conflicts", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep07-merge-conflicts-chapters.json", + "chapterCount": 13, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Merge Conflicts Are Not Scary: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Understanding, Preventing, and Resolving Conflicts", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 4, + "title": "What Is a Merge Conflict?", + "startSegmentIndex": 47, + "score": "strong" + }, + { + "index": 5, + "title": "How to Prevent Conflicts (Prevention is Easier Than Resolution)", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 6, + "title": "Advanced Prevention: Understanding Fast-Forward Merges", + "startSegmentIndex": 78, + "score": "strong" + }, + { + "index": 7, + "title": "When Conflicts Are Actually Good", + "startSegmentIndex": 83, + "score": "strong" + }, + { + "index": 8, + "title": "Conflict Markers - What They Mean", + "startSegmentIndex": 93, + "score": "strong" + }, + { + "index": 9, + "title": "Resolving Conflicts on GitHub (Web Editor)", + "startSegmentIndex": 109, + "score": "strong" + }, + { + "index": 10, + "title": "Resolving Conflicts in VS Code (Day 2)", + "startSegmentIndex": 124, + "score": "strong" + }, + { + "index": 11, + "title": "Reading a Conflict Message from Git (Command Line Reference)", + "startSegmentIndex": 145, + "score": "strong" + }, + { + "index": 12, + "title": "Read a Conflict (Without Fear)", + "startSegmentIndex": 148, + "score": "strong" + }, + { + "index": 13, + "title": "Merge Conflicts Are Not Scary: Wrap-Up", + "startSegmentIndex": 152, + "score": "strong" + } + ] + }, + { + "slug": "ep08-culture-and-etiquette", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep08-culture-and-etiquette-chapters.json", + "chapterCount": 26, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Open Source Culture and Etiquette: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "How to Be an Effective and Respectful Open Source Contributor", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 4, + "title": "GitHub Flow - The Standard Contribution Workflow", + "startSegmentIndex": 40, + "score": "strong" + }, + { + "index": 5, + "title": "Keeping Your Fork Up to Date", + "startSegmentIndex": 69, + "score": "strong" + }, + { + "index": 6, + "title": "When to sync", + "startSegmentIndex": 90, + "score": "strong" + }, + { + "index": 7, + "title": "Writing Good Commit Messages", + "startSegmentIndex": 102, + "score": "strong" + }, + { + "index": 8, + "title": "The Nature of Open Source Communication", + "startSegmentIndex": 125, + "score": "strong" + }, + { + "index": 9, + "title": "The Anatomy of Helpful Feedback", + "startSegmentIndex": 137, + "score": "strong" + }, + { + "index": 10, + "title": "Inclusive Commenting for Accessibility Issues", + "startSegmentIndex": 201, + "score": "strong" + }, + { + "index": 11, + "title": "The \"Good First Issue\" Social Contract", + "startSegmentIndex": 204, + "score": "strong" + }, + { + "index": 12, + "title": "Writing Your First README", + "startSegmentIndex": 224, + "score": "strong" + }, + { + "index": 13, + "title": "Community Health Files", + "startSegmentIndex": 236, + "score": "strong" + }, + { + "index": 14, + "title": "When to Use Different Communication Channels", + "startSegmentIndex": 252, + "score": "strong" + }, + { + "index": 15, + "title": "Rewrite One Comment", + "startSegmentIndex": 255, + "score": "strong" + }, + { + "index": 16, + "title": "Contributing to Open Source", + "startSegmentIndex": 261, + "score": "strong" + }, + { + "index": 17, + "title": "A Guide for First-Time Contributors", + "startSegmentIndex": 263, + "score": "strong" + }, + { + "index": 18, + "title": "1. What Is Open Source?", + "startSegmentIndex": 264, + "score": "strong" + }, + { + "index": 19, + "title": "2. Who Can Contribute?", + "startSegmentIndex": 268, + "score": "strong" + }, + { + "index": 20, + "title": "3. What Makes a Good First Contribution?", + "startSegmentIndex": 269, + "score": "strong" + }, + { + "index": 21, + "title": "4. Finding Something to Work On", + "startSegmentIndex": 275, + "score": "strong" + }, + { + "index": 22, + "title": "5. Reading an Issue Before You Start", + "startSegmentIndex": 279, + "score": "strong" + }, + { + "index": 23, + "title": "7. Getting Help", + "startSegmentIndex": 297, + "score": "strong" + }, + { + "index": 24, + "title": "8. After Your Contribution Is Merged", + "startSegmentIndex": 300, + "score": "strong" + }, + { + "index": 25, + "title": "9. Building a Contribution Habit", + "startSegmentIndex": 302, + "score": "strong" + }, + { + "index": 26, + "title": "Open Source Culture and Etiquette: Wrap-Up", + "startSegmentIndex": 308, + "score": "strong" + } + ] + }, + { + "slug": "ep09-labels-milestones-projects", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep09-labels-milestones-projects-chapters.json", + "chapterCount": 8, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Labels, Milestones, and Projects: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Organizing Work and Cross-Referencing on GitHub", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 4, + "title": "Cross-References", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 5, + "title": "GitHub Projects", + "startSegmentIndex": 109, + "score": "strong" + }, + { + "index": 6, + "title": "Practical Organization Strategy for the Hackathon", + "startSegmentIndex": 134, + "score": "strong" + }, + { + "index": 7, + "title": "Label and Link", + "startSegmentIndex": 135, + "score": "strong" + }, + { + "index": 8, + "title": "Labels, Milestones, and Projects: Wrap-Up", + "startSegmentIndex": 139, + "score": "strong" + } + ] + }, + { + "slug": "ep10-notifications", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep10-notifications-chapters.json", + "chapterCount": 14, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Notifications and Mentions: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Managing Your GitHub Notification Inbox", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 4, + "title": "What Generates a Notification?", + "startSegmentIndex": 40, + "score": "strong" + }, + { + "index": 5, + "title": "Notification Subscription Levels", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 6, + "title": "Inbox Actions - Keyboard Shortcuts", + "startSegmentIndex": 65, + "score": "strong" + }, + { + "index": 7, + "title": "Filtering the Inbox", + "startSegmentIndex": 67, + "score": "strong" + }, + { + "index": 8, + "title": "Notification Settings - Per Your Account", + "startSegmentIndex": 93, + "score": "strong" + }, + { + "index": 9, + "title": "Starring vs. Watching - What Is the Difference?", + "startSegmentIndex": 95, + "score": "strong" + }, + { + "index": 10, + "title": "The GitHub Mobile App - A Reference Note", + "startSegmentIndex": 115, + "score": "strong" + }, + { + "index": 11, + "title": "Tame Your Inbox", + "startSegmentIndex": 121, + "score": "strong" + }, + { + "index": 12, + "title": "What You Accomplished Today", + "startSegmentIndex": 124, + "score": "strong" + }, + { + "index": 13, + "title": "What Day 2 Adds", + "startSegmentIndex": 138, + "score": "strong" + }, + { + "index": 14, + "title": "Notifications and Mentions: Wrap-Up", + "startSegmentIndex": 144, + "score": "strong" + } + ] + }, + { + "slug": "ep11-vscode-basics", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep11-vscode-basics-chapters.json", + "chapterCount": 14, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "VS Code Setup and Accessibility: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Your Accessible Development Environment - The Foundation", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 4, + "title": "1. Why VS Code for Open Source Contribution", + "startSegmentIndex": 43, + "score": "strong" + }, + { + "index": 5, + "title": "3. Screen Reader Mode in VS Code", + "startSegmentIndex": 111, + "score": "strong" + }, + { + "index": 6, + "title": "4. The VS Code Interface Tour", + "startSegmentIndex": 129, + "score": "strong" + }, + { + "index": 7, + "title": "5. The Accounts Button and GitHub Sign-In", + "startSegmentIndex": 139, + "score": "strong" + }, + { + "index": 8, + "title": "6. Verifying GitHub Copilot Status", + "startSegmentIndex": 158, + "score": "strong" + }, + { + "index": 9, + "title": "7. The Status Bar", + "startSegmentIndex": 172, + "score": "strong" + }, + { + "index": 10, + "title": "8. The Menu Bar", + "startSegmentIndex": 179, + "score": "strong" + }, + { + "index": 11, + "title": "9. Settings Sync", + "startSegmentIndex": 184, + "score": "strong" + }, + { + "index": 12, + "title": "10. The Settings Editor", + "startSegmentIndex": 210, + "score": "strong" + }, + { + "index": 13, + "title": "11. The Keyboard Shortcuts Editor", + "startSegmentIndex": 216, + "score": "strong" + }, + { + "index": 14, + "title": "VS Code Setup and Accessibility: Wrap-Up", + "startSegmentIndex": 227, + "score": "strong" + } + ] + }, + { + "slug": "ep12-git-source-control", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep12-git-source-control-chapters.json", + "chapterCount": 17, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Git and Source Control in VS Code: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Managing Repositories, Branches, and Changes Accessibly", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 45, + "score": "strong" + }, + { + "index": 4, + "title": "2. The Source Control Panel - Complete Walkthrough", + "startSegmentIndex": 99, + "score": "strong" + }, + { + "index": 5, + "title": "3. Branch Management", + "startSegmentIndex": 131, + "score": "strong" + }, + { + "index": 6, + "title": "4. Staging Changes - Files, Lines, and Chunks", + "startSegmentIndex": 203, + "score": "strong" + }, + { + "index": 7, + "title": "6. Push and Pull Operations", + "startSegmentIndex": 269, + "score": "strong" + }, + { + "index": 8, + "title": "What to do if push fails", + "startSegmentIndex": 300, + "score": "strong" + }, + { + "index": 9, + "title": "Syncing Your Fork with the Upstream Repository", + "startSegmentIndex": 312, + "score": "strong" + }, + { + "index": 10, + "title": "7. Discarding Changes", + "startSegmentIndex": 334, + "score": "strong" + }, + { + "index": 11, + "title": "8. Timeline View - File History and Blame", + "startSegmentIndex": 379, + "score": "strong" + }, + { + "index": 12, + "title": "9. Resolving Merge Conflicts in VS Code", + "startSegmentIndex": 430, + "score": "strong" + }, + { + "index": 13, + "title": "10. Stash Management", + "startSegmentIndex": 452, + "score": "strong" + }, + { + "index": 14, + "title": "10b. Emergency Recovery - git reflog", + "startSegmentIndex": 505, + "score": "strong" + }, + { + "index": 15, + "title": "11. Alternative Git Interfaces", + "startSegmentIndex": 525, + "score": "strong" + }, + { + "index": 16, + "title": "Clone, Branch, Commit", + "startSegmentIndex": 541, + "score": "strong" + }, + { + "index": 17, + "title": "Git and Source Control in VS Code: Wrap-Up", + "startSegmentIndex": 547, + "score": "strong" + } + ] + }, + { + "slug": "ep13-github-prs-extension", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep13-github-prs-extension-chapters.json", + "chapterCount": 21, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "The GitHub Pull Requests Extension: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "The GitHub Pull Requests Extension", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Managing Pull Requests from VS Code", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "Why Issues Matter", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 5, + "title": "1. Installing the GitHub Pull Requests Extension", + "startSegmentIndex": 46, + "score": "strong" + }, + { + "index": 6, + "title": "Method 2: Explorer Section", + "startSegmentIndex": 83, + "score": "strong" + }, + { + "index": 7, + "title": "3. Checking Out a Pull Request Branch", + "startSegmentIndex": 103, + "score": "strong" + }, + { + "index": 8, + "title": "4. Reviewing Pull Requests in VS Code", + "startSegmentIndex": 130, + "score": "strong" + }, + { + "index": 9, + "title": "6. Pull Request Description Templates", + "startSegmentIndex": 217, + "score": "strong" + }, + { + "index": 10, + "title": "7. Commenting and Requesting Changes", + "startSegmentIndex": 230, + "score": "strong" + }, + { + "index": 11, + "title": "8. Merging Pull Requests", + "startSegmentIndex": 262, + "score": "strong" + }, + { + "index": 12, + "title": "Review a PR from VS Code", + "startSegmentIndex": 310, + "score": "strong" + }, + { + "index": 13, + "title": "Conducting Pull Request Reviews with a Screen Reader", + "startSegmentIndex": 316, + "score": "strong" + }, + { + "index": 14, + "title": "Why Issues Matter", + "startSegmentIndex": 346, + "score": "strong" + }, + { + "index": 15, + "title": "Two Environments for Code Review", + "startSegmentIndex": 354, + "score": "strong" + }, + { + "index": 16, + "title": "Reviewing in VS Code with the Accessible Diff Viewer", + "startSegmentIndex": 410, + "score": "strong" + }, + { + "index": 17, + "title": "Exercises", + "startSegmentIndex": 472, + "score": "strong" + }, + { + "index": 18, + "title": "Using GitHub Copilot to Understand Code Changes", + "startSegmentIndex": 599, + "score": "strong" + }, + { + "index": 19, + "title": "The Reviewer's Craft", + "startSegmentIndex": 624, + "score": "strong" + }, + { + "index": 20, + "title": "Day 2 Teaser: The Full Accessibility Agents Review Ecosystem", + "startSegmentIndex": 640, + "score": "strong" + }, + { + "index": 21, + "title": "The GitHub Pull Requests Extension: Wrap-Up", + "startSegmentIndex": 661, + "score": "strong" + } + ] + }, + { + "slug": "ep14-github-copilot", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep14-github-copilot-chapters.json", + "chapterCount": 16, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Copilot: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "AI-Powered Code Assistance in VS Code", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 45, + "score": "strong" + }, + { + "index": 4, + "title": "1. What is GitHub Copilot", + "startSegmentIndex": 51, + "score": "strong" + }, + { + "index": 5, + "title": "3. Inline Suggestions - Ghost Text Completions", + "startSegmentIndex": 77, + "score": "strong" + }, + { + "index": 6, + "title": "4. GitHub Copilot Chat - Conversational Assistance", + "startSegmentIndex": 126, + "score": "strong" + }, + { + "index": 7, + "title": "5. Copilot Edits -- Making Multi-File Changes", + "startSegmentIndex": 164, + "score": "strong" + }, + { + "index": 8, + "title": "6. Agent Mode -- Let Copilot Drive", + "startSegmentIndex": 183, + "score": "strong" + }, + { + "index": 9, + "title": "7. Next Edit Suggestions", + "startSegmentIndex": 196, + "score": "strong" + }, + { + "index": 10, + "title": "8. Copilot on GitHub.com", + "startSegmentIndex": 203, + "score": "strong" + }, + { + "index": 11, + "title": "9. Effective Prompting for Documentation Work", + "startSegmentIndex": 220, + "score": "strong" + }, + { + "index": 12, + "title": "10. Custom Instructions vs Custom Agents", + "startSegmentIndex": 240, + "score": "strong" + }, + { + "index": 13, + "title": "11. Using Accessible View with Copilot Responses", + "startSegmentIndex": 287, + "score": "strong" + }, + { + "index": 14, + "title": "13. Critically Evaluating AI Output", + "startSegmentIndex": 322, + "score": "strong" + }, + { + "index": 15, + "title": "Your First Copilot Conversation", + "startSegmentIndex": 368, + "score": "strong" + }, + { + "index": 16, + "title": "GitHub Copilot: Wrap-Up", + "startSegmentIndex": 372, + "score": "strong" + } + ] + }, + { + "slug": "ep15-accessible-code-review", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep15-accessible-code-review-chapters.json", + "chapterCount": 21, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Accessible Code Review: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "The GitHub Pull Requests Extension", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Managing Pull Requests from VS Code", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "Why Issues Matter", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 5, + "title": "1. Installing the GitHub Pull Requests Extension", + "startSegmentIndex": 46, + "score": "strong" + }, + { + "index": 6, + "title": "Method 2: Explorer Section", + "startSegmentIndex": 83, + "score": "strong" + }, + { + "index": 7, + "title": "3. Checking Out a Pull Request Branch", + "startSegmentIndex": 103, + "score": "strong" + }, + { + "index": 8, + "title": "4. Reviewing Pull Requests in VS Code", + "startSegmentIndex": 130, + "score": "strong" + }, + { + "index": 9, + "title": "6. Pull Request Description Templates", + "startSegmentIndex": 217, + "score": "strong" + }, + { + "index": 10, + "title": "7. Commenting and Requesting Changes", + "startSegmentIndex": 230, + "score": "strong" + }, + { + "index": 11, + "title": "8. Merging Pull Requests", + "startSegmentIndex": 262, + "score": "strong" + }, + { + "index": 12, + "title": "Review a PR from VS Code", + "startSegmentIndex": 310, + "score": "strong" + }, + { + "index": 13, + "title": "Conducting Pull Request Reviews with a Screen Reader", + "startSegmentIndex": 316, + "score": "strong" + }, + { + "index": 14, + "title": "Why Issues Matter", + "startSegmentIndex": 346, + "score": "strong" + }, + { + "index": 15, + "title": "Two Environments for Code Review", + "startSegmentIndex": 354, + "score": "strong" + }, + { + "index": 16, + "title": "Reviewing in VS Code with the Accessible Diff Viewer", + "startSegmentIndex": 410, + "score": "strong" + }, + { + "index": 17, + "title": "Exercises", + "startSegmentIndex": 472, + "score": "strong" + }, + { + "index": 18, + "title": "Using GitHub Copilot to Understand Code Changes", + "startSegmentIndex": 599, + "score": "strong" + }, + { + "index": 19, + "title": "The Reviewer's Craft", + "startSegmentIndex": 624, + "score": "strong" + }, + { + "index": 20, + "title": "Day 2 Teaser: The Full Accessibility Agents Review Ecosystem", + "startSegmentIndex": 640, + "score": "strong" + }, + { + "index": 21, + "title": "Accessible Code Review: Wrap-Up", + "startSegmentIndex": 661, + "score": "strong" + } + ] + }, + { + "slug": "ep16-issue-templates", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep16-issue-templates-chapters.json", + "chapterCount": 12, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Issue Templates: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Structuring Contributions for Clarity and Quality", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 53, + "score": "strong" + }, + { + "index": 4, + "title": "1. What Is an Issue Template?", + "startSegmentIndex": 60, + "score": "strong" + }, + { + "index": 5, + "title": "2. How Templates Work on GitHub", + "startSegmentIndex": 66, + "score": "strong" + }, + { + "index": 6, + "title": "3. Navigating the Template Picker", + "startSegmentIndex": 76, + "score": "strong" + }, + { + "index": 7, + "title": "4. The Accessibility Agents Issue Templates", + "startSegmentIndex": 87, + "score": "strong" + }, + { + "index": 8, + "title": "6. YAML Form-Based Templates", + "startSegmentIndex": 152, + "score": "strong" + }, + { + "index": 9, + "title": "7. Building an Accessibility Bug Report Template", + "startSegmentIndex": 187, + "score": "strong" + }, + { + "index": 10, + "title": "8. Pull Request Templates", + "startSegmentIndex": 200, + "score": "strong" + }, + { + "index": 11, + "title": "10. Day 2 Amplifier: The Template Builder Agent", + "startSegmentIndex": 410, + "score": "strong" + }, + { + "index": 12, + "title": "Issue Templates: Wrap-Up", + "startSegmentIndex": 418, + "score": "strong" + } + ] + }, + { + "slug": "ep17-accessibility-agents", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep17-accessibility-agents-chapters.json", + "chapterCount": 13, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Accessibility Agents: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "55 AI Agents Across 3 Teams and 5 Platforms", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 58, + "score": "strong" + }, + { + "index": 4, + "title": "Capstone: Share Your Feedback (The Most Important Task!)", + "startSegmentIndex": 65, + "score": "strong" + }, + { + "index": 5, + "title": "1. The Principle: Skill First, Agent Second", + "startSegmentIndex": 70, + "score": "strong" + }, + { + "index": 6, + "title": "3. The Ecosystem: 55 Agents, 3 Teams, 5 Platforms", + "startSegmentIndex": 138, + "score": "strong" + }, + { + "index": 7, + "title": "4. Agents in Detail - Hands-On Reference", + "startSegmentIndex": 165, + "score": "strong" + }, + { + "index": 8, + "title": "5. Slash Commands and Prompts", + "startSegmentIndex": 214, + "score": "strong" + }, + { + "index": 9, + "title": "6. Contributing to the Ecosystem", + "startSegmentIndex": 223, + "score": "strong" + }, + { + "index": 10, + "title": "7. The Bigger Picture: Teams, Orchestration, and Beyond VS Code", + "startSegmentIndex": 301, + "score": "strong" + }, + { + "index": 11, + "title": "8. GitHub Desktop, GitHub CLI, and Copilot CLI", + "startSegmentIndex": 329, + "score": "strong" + }, + { + "index": 12, + "title": "Example session", + "startSegmentIndex": 351, + "score": "strong" + }, + { + "index": 13, + "title": "Accessibility Agents: Wrap-Up", + "startSegmentIndex": 371, + "score": "strong" + } + ] + }, + { + "slug": "ep44-choose-your-tools", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep44-choose-your-tools-chapters.json", + "chapterCount": 12, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Choose Your Tools: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "1. Why This Matters", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. The Five Paths", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "3. Path 1: GitHub.com (Browser)", + "startSegmentIndex": 10, + "score": "strong" + }, + { + "index": 5, + "title": "4. Path 2: github.dev (Browser-Based Editor)", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 6, + "title": "5. Path 3: VS Code (Desktop)", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 7, + "title": "6. Path 4: GitHub Desktop", + "startSegmentIndex": 59, + "score": "strong" + }, + { + "index": 8, + "title": "7. Path 5: GitHub CLI", + "startSegmentIndex": 71, + "score": "strong" + }, + { + "index": 9, + "title": "8. Which Path Should I Start With?", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 10, + "title": "9. Your First Confidence Exercise", + "startSegmentIndex": 97, + "score": "strong" + }, + { + "index": 11, + "title": "10. If You Get Stuck", + "startSegmentIndex": 126, + "score": "strong" + }, + { + "index": 12, + "title": "Choose Your Tools: Wrap-Up", + "startSegmentIndex": 129, + "score": "strong" + } + ] + }, + { + "slug": "ep45-vscode-accessibility-deep-dive", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep45-vscode-accessibility-deep-dive-chapters.json", + "chapterCount": 10, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "VS Code Accessibility Deep Dive: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Accessibility Features for Power Users", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "13. The Problems Panel", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 4, + "title": "14. The Terminal", + "startSegmentIndex": 40, + "score": "strong" + }, + { + "index": 5, + "title": "15. Copilot Chat Window", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 6, + "title": "16. Accessible Help, Accessible View, and Accessible Diff", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 7, + "title": "17. Accessibility Signals", + "startSegmentIndex": 100, + "score": "strong" + }, + { + "index": 8, + "title": "18. VS Code Speech - Voice Input and Output", + "startSegmentIndex": 132, + "score": "strong" + }, + { + "index": 9, + "title": "19. Markdown Authoring in VS Code", + "startSegmentIndex": 162, + "score": "strong" + }, + { + "index": 10, + "title": "VS Code Accessibility Deep Dive: Wrap-Up", + "startSegmentIndex": 181, + "score": "strong" + } + ] + }, + { + "slug": "ep46-how-git-works", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep46-how-git-works-chapters.json", + "chapterCount": 12, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "How Git Works: The Mental Model: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "1. Why a Mental Model Matters", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. The Three Areas: Working Directory, Staging Area, Repository", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "3. What Is a Commit?", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 5, + "title": "4. What Is a Branch?", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 6, + "title": "5. Local vs Remote", + "startSegmentIndex": 54, + "score": "strong" + }, + { + "index": 7, + "title": "6. Push, Pull, and Fetch", + "startSegmentIndex": 66, + "score": "strong" + }, + { + "index": 8, + "title": "7. Why Merge Conflicts Happen", + "startSegmentIndex": 78, + "score": "strong" + }, + { + "index": 9, + "title": "8. The Git Timeline", + "startSegmentIndex": 97, + "score": "strong" + }, + { + "index": 10, + "title": "9. Putting It All Together", + "startSegmentIndex": 104, + "score": "strong" + }, + { + "index": 11, + "title": "10. If You Get Stuck", + "startSegmentIndex": 111, + "score": "strong" + }, + { + "index": 12, + "title": "How Git Works: The Mental Model: Wrap-Up", + "startSegmentIndex": 113, + "score": "strong" + } + ] + }, + { + "slug": "ep47-fork-and-contribute", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep47-fork-and-contribute-chapters.json", + "chapterCount": 14, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Fork and Contribute: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "1. What Is a Fork?", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. Fork vs Clone vs Branch", + "startSegmentIndex": 12, + "score": "strong" + }, + { + "index": 4, + "title": "4. Step 2: Clone Your Fork Locally", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 5, + "title": "5. Step 3: Add the Upstream Remote", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 6, + "title": "6. Step 4: Create a Feature Branch", + "startSegmentIndex": 77, + "score": "strong" + }, + { + "index": 7, + "title": "7. Step 5: Make Your Changes", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 8, + "title": "8. Step 6: Push to Your Fork", + "startSegmentIndex": 109, + "score": "strong" + }, + { + "index": 9, + "title": "9. Step 7: Open a Pull Request", + "startSegmentIndex": 125, + "score": "strong" + }, + { + "index": 10, + "title": "10. Step 8: Respond to Review Feedback", + "startSegmentIndex": 148, + "score": "strong" + }, + { + "index": 11, + "title": "11. Keeping Your Fork in Sync", + "startSegmentIndex": 159, + "score": "strong" + }, + { + "index": 12, + "title": "12. The Fork Workflow Checklist", + "startSegmentIndex": 177, + "score": "strong" + }, + { + "index": 13, + "title": "13. If You Get Stuck", + "startSegmentIndex": 183, + "score": "strong" + }, + { + "index": 14, + "title": "Fork and Contribute: Wrap-Up", + "startSegmentIndex": 186, + "score": "strong" + } + ] + }, + { + "slug": "ep48-build-your-agent-capstone", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep48-build-your-agent-capstone-chapters.json", + "chapterCount": 10, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Build Your Agent: Capstone: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "1. The Capstone Challenge", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. Phase 1: Choose Your Agent's Mission", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 4, + "title": "3. Phase 2: Write the Agent File", + "startSegmentIndex": 25, + "score": "strong" + }, + { + "index": 5, + "title": "4. Phase 3: Define Responsibilities and Guardrails", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 6, + "title": "5. Phase 4: Test Your Agent Locally", + "startSegmentIndex": 53, + "score": "strong" + }, + { + "index": 7, + "title": "7. Phase 6: Respond to Review", + "startSegmentIndex": 96, + "score": "strong" + }, + { + "index": 8, + "title": "8. Capstone Rubric", + "startSegmentIndex": 109, + "score": "strong" + }, + { + "index": 9, + "title": "9. Example Agents for Inspiration", + "startSegmentIndex": 119, + "score": "strong" + }, + { + "index": 10, + "title": "Build Your Agent: Capstone: Wrap-Up", + "startSegmentIndex": 133, + "score": "strong" + } + ] + }, + { + "slug": "ep49-next-steps", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep49-next-steps-chapters.json", + "chapterCount": 9, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "What Comes Next: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "1. What You Built in Two Days", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. Your New Skills Inventory", + "startSegmentIndex": 18, + "score": "strong" + }, + { + "index": 4, + "title": "3. Building Your Developer Portfolio", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 5, + "title": "4. Continued Learning Roadmap", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 6, + "title": "5. GitHub Skills Courses to Try Next", + "startSegmentIndex": 56, + "score": "strong" + }, + { + "index": 7, + "title": "7. Contributing Back to This Workshop", + "startSegmentIndex": 71, + "score": "strong" + }, + { + "index": 8, + "title": "8. Final Words", + "startSegmentIndex": 82, + "score": "strong" + }, + { + "index": 9, + "title": "What Comes Next: Wrap-Up", + "startSegmentIndex": 84, + "score": "strong" + } + ] + }, + { + "slug": "ep18-glossary", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep18-glossary-chapters.json", + "chapterCount": 7, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Glossary of Terms: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Every Term You Need for Open Source Contribution", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Common Abbreviations and Slang", + "startSegmentIndex": 91, + "score": "strong" + }, + { + "index": 4, + "title": "Stash commands", + "startSegmentIndex": 119, + "score": "strong" + }, + { + "index": 5, + "title": "Community Files", + "startSegmentIndex": 178, + "score": "strong" + }, + { + "index": 6, + "title": "Alphabetical Quick Reference", + "startSegmentIndex": 183, + "score": "strong" + }, + { + "index": 7, + "title": "Glossary of Terms: Wrap-Up", + "startSegmentIndex": 185, + "score": "strong" + } + ] + }, + { + "slug": "ep19-screen-reader-cheatsheet", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep19-screen-reader-cheatsheet-chapters.json", + "chapterCount": 12, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Screen Reader Cheat Sheet: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "GitHub Navigation with NVDA, JAWS, and VoiceOver", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Screen Reader Mode Basics", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "Quick Navigation Keys (Browse Mode)", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 5, + "title": "The Elements List - Your Navigation Superpower", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 6, + "title": "Per-Screen-Reader Command Reference", + "startSegmentIndex": 32, + "score": "strong" + }, + { + "index": 7, + "title": "Dropdown Menus and Flyouts", + "startSegmentIndex": 51, + "score": "strong" + }, + { + "index": 8, + "title": "GitHub Built-In Keyboard Shortcuts", + "startSegmentIndex": 58, + "score": "strong" + }, + { + "index": 9, + "title": "Official Screen Reader Resources", + "startSegmentIndex": 103, + "score": "strong" + }, + { + "index": 10, + "title": "Keyboard Shortcuts in Other Appendices", + "startSegmentIndex": 106, + "score": "strong" + }, + { + "index": 11, + "title": "Screen Reader Compatibility Notes", + "startSegmentIndex": 109, + "score": "strong" + }, + { + "index": 12, + "title": "Screen Reader Cheat Sheet: Wrap-Up", + "startSegmentIndex": 116, + "score": "strong" + } + ] + }, + { + "slug": "ep20-accessibility-standards", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep20-accessibility-standards-chapters.json", + "chapterCount": 10, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Accessibility Standards Reference: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "WCAG, ARIA, and What They Mean for Your Contributions", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. WCAG 2.2 - The Four Principles", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "2. Conformance Levels: A, AA, AAA", + "startSegmentIndex": 16, + "score": "strong" + }, + { + "index": 5, + "title": "3. Key Success Criteria for Web Contributions", + "startSegmentIndex": 17, + "score": "strong" + }, + { + "index": 6, + "title": "4. ARIA - Roles, States, and Properties", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 7, + "title": "5. ARIA Landmark Roles", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 8, + "title": "7. How Standards Apply to GitHub Contributions", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 9, + "title": "10. Official References", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 10, + "title": "Accessibility Standards Reference: Wrap-Up", + "startSegmentIndex": 53, + "score": "strong" + } + ] + }, + { + "slug": "ep21-git-authentication", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep21-git-authentication-chapters.json", + "chapterCount": 11, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Git Authentication: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "SSH Keys & Personal Access Tokens", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "When You Need Authentication", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "Creating a Personal Access Token (Recommended for This Workshop)", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 5, + "title": "Setting Up SSH Keys (Alternative Method)", + "startSegmentIndex": 52, + "score": "strong" + }, + { + "index": 6, + "title": "Switching Between HTTPS and SSH", + "startSegmentIndex": 74, + "score": "strong" + }, + { + "index": 7, + "title": "Security Best Practices", + "startSegmentIndex": 106, + "score": "strong" + }, + { + "index": 8, + "title": "Commit Signing - Verified Badges and Vigilant Mode", + "startSegmentIndex": 111, + "score": "strong" + }, + { + "index": 9, + "title": "Step 4: Add to GitHub", + "startSegmentIndex": 125, + "score": "strong" + }, + { + "index": 10, + "title": "Step 5: Configure Git to sign all commits", + "startSegmentIndex": 127, + "score": "strong" + }, + { + "index": 11, + "title": "Git Authentication: Wrap-Up", + "startSegmentIndex": 147, + "score": "strong" + } + ] + }, + { + "slug": "ep22-github-flavored-markdown", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep22-github-flavored-markdown-chapters.json", + "chapterCount": 35, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Flavored Markdown: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "From First Paragraph to Polished Repository - Everything You.", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. What Is Markdown?", + "startSegmentIndex": 30, + "score": "strong" + }, + { + "index": 4, + "title": "2. Where You Will Use Markdown in This Workshop", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 5, + "title": "3. How to Practice as You Read", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 6, + "title": "4. Paragraphs and Line Breaks", + "startSegmentIndex": 65, + "score": "strong" + }, + { + "index": 7, + "title": "5. Headings", + "startSegmentIndex": 75, + "score": "strong" + }, + { + "index": 8, + "title": "6. Emphasis - Bold, Italic, and Bold Italic", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 9, + "title": "7. Strikethrough", + "startSegmentIndex": 101, + "score": "strong" + }, + { + "index": 10, + "title": "8. Lists - Ordered and Unordered", + "startSegmentIndex": 102, + "score": "strong" + }, + { + "index": 11, + "title": "9. Nested Lists and Mixed Lists", + "startSegmentIndex": 116, + "score": "strong" + }, + { + "index": 12, + "title": "10. Links", + "startSegmentIndex": 131, + "score": "strong" + }, + { + "index": 13, + "title": "11. Images", + "startSegmentIndex": 149, + "score": "strong" + }, + { + "index": 14, + "title": "12. Blockquotes", + "startSegmentIndex": 161, + "score": "strong" + }, + { + "index": 15, + "title": "13. Inline Code and Code Blocks", + "startSegmentIndex": 170, + "score": "strong" + }, + { + "index": 16, + "title": "14. Horizontal Rules", + "startSegmentIndex": 188, + "score": "strong" + }, + { + "index": 17, + "title": "15. Escaping Special Characters", + "startSegmentIndex": 189, + "score": "strong" + }, + { + "index": 18, + "title": "16. Tables", + "startSegmentIndex": 195, + "score": "strong" + }, + { + "index": 19, + "title": "17. What Is GitHub Flavored Markdown?", + "startSegmentIndex": 217, + "score": "strong" + }, + { + "index": 20, + "title": "18. Alert and Callout Blocks", + "startSegmentIndex": 221, + "score": "strong" + }, + { + "index": 21, + "title": "19. Collapsible Sections with Details and Summary", + "startSegmentIndex": 231, + "score": "strong" + }, + { + "index": 22, + "title": "20. Task List Checkboxes", + "startSegmentIndex": 249, + "score": "strong" + }, + { + "index": 23, + "title": "21. Syntax Highlighting in Fenced Code Blocks", + "startSegmentIndex": 265, + "score": "strong" + }, + { + "index": 24, + "title": "22. Mermaid Diagrams", + "startSegmentIndex": 272, + "score": "strong" + }, + { + "index": 25, + "title": "23. Math Expressions with LaTeX", + "startSegmentIndex": 283, + "score": "strong" + }, + { + "index": 26, + "title": "24. Footnotes", + "startSegmentIndex": 293, + "score": "strong" + }, + { + "index": 27, + "title": "25. Linked Heading Anchors and Tables of Contents", + "startSegmentIndex": 306, + "score": "strong" + }, + { + "index": 28, + "title": "26. Autolinked References - Issues, PRs, Commits, and Users", + "startSegmentIndex": 318, + "score": "strong" + }, + { + "index": 29, + "title": "27. HTML in Markdown", + "startSegmentIndex": 329, + "score": "strong" + }, + { + "index": 30, + "title": "28. Screen Reader Behavior Summary", + "startSegmentIndex": 342, + "score": "strong" + }, + { + "index": 31, + "title": "29. Accessible Markdown Authoring Checklist", + "startSegmentIndex": 343, + "score": "strong" + }, + { + "index": 32, + "title": "30. Common Mistakes and How to Fix Them", + "startSegmentIndex": 368, + "score": "strong" + }, + { + "index": 33, + "title": "31. Your First Real Markdown Document - Guided Exercise", + "startSegmentIndex": 388, + "score": "strong" + }, + { + "index": 34, + "title": "32. Quick-Reference Card", + "startSegmentIndex": 414, + "score": "strong" + }, + { + "index": 35, + "title": "GitHub Flavored Markdown: Wrap-Up", + "startSegmentIndex": 420, + "score": "strong" + } + ] + }, + { + "slug": "ep23-github-gists", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep23-github-gists-chapters.json", + "chapterCount": 22, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Gists: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Forum-Style Conversations Beyond Issues and Pull Requests", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Discussions vs. Issues: When to Use Which", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 4, + "title": "3. Discussion Categories", + "startSegmentIndex": 32, + "score": "strong" + }, + { + "index": 5, + "title": "4. Creating a Discussion", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 6, + "title": "6. Marking an Answer", + "startSegmentIndex": 60, + "score": "strong" + }, + { + "index": 7, + "title": "7. Polls", + "startSegmentIndex": 68, + "score": "strong" + }, + { + "index": 8, + "title": "9. Organization-Level Discussions", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 9, + "title": "10. Accessibility Agents: What's Different Here", + "startSegmentIndex": 89, + "score": "strong" + }, + { + "index": 10, + "title": "Shareable Code Snippets and Notes", + "startSegmentIndex": 92, + "score": "strong" + }, + { + "index": 11, + "title": "What Is a Gist?", + "startSegmentIndex": 99, + "score": "strong" + }, + { + "index": 12, + "title": "When to Use a Gist vs a Repository", + "startSegmentIndex": 102, + "score": "strong" + }, + { + "index": 13, + "title": "Editing a Gist", + "startSegmentIndex": 122, + "score": "strong" + }, + { + "index": 14, + "title": "Embedding a Gist", + "startSegmentIndex": 125, + "score": "strong" + }, + { + "index": 15, + "title": "Cloning a Gist", + "startSegmentIndex": 127, + "score": "strong" + }, + { + "index": 16, + "title": "Forking a Gist", + "startSegmentIndex": 130, + "score": "strong" + }, + { + "index": 17, + "title": "Finding Your Gists", + "startSegmentIndex": 135, + "score": "strong" + }, + { + "index": 18, + "title": "Discovering Public Gists", + "startSegmentIndex": 141, + "score": "strong" + }, + { + "index": 19, + "title": "Gist Comments", + "startSegmentIndex": 144, + "score": "strong" + }, + { + "index": 20, + "title": "Gists vs GitHub Repositories - Quick Comparison", + "startSegmentIndex": 167, + "score": "strong" + }, + { + "index": 21, + "title": "Deleting a Gist", + "startSegmentIndex": 170, + "score": "strong" + }, + { + "index": 22, + "title": "GitHub Gists: Wrap-Up", + "startSegmentIndex": 174, + "score": "strong" + } + ] + }, + { + "slug": "ep24-github-discussions", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep24-github-discussions-chapters.json", + "chapterCount": 22, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Discussions: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Forum-Style Conversations Beyond Issues and Pull Requests", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Discussions vs. Issues: When to Use Which", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 4, + "title": "3. Discussion Categories", + "startSegmentIndex": 32, + "score": "strong" + }, + { + "index": 5, + "title": "4. Creating a Discussion", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 6, + "title": "6. Marking an Answer", + "startSegmentIndex": 60, + "score": "strong" + }, + { + "index": 7, + "title": "7. Polls", + "startSegmentIndex": 68, + "score": "strong" + }, + { + "index": 8, + "title": "9. Organization-Level Discussions", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 9, + "title": "10. Accessibility Agents: What's Different Here", + "startSegmentIndex": 89, + "score": "strong" + }, + { + "index": 10, + "title": "Shareable Code Snippets and Notes", + "startSegmentIndex": 92, + "score": "strong" + }, + { + "index": 11, + "title": "What Is a Gist?", + "startSegmentIndex": 99, + "score": "strong" + }, + { + "index": 12, + "title": "When to Use a Gist vs a Repository", + "startSegmentIndex": 102, + "score": "strong" + }, + { + "index": 13, + "title": "Editing a Gist", + "startSegmentIndex": 122, + "score": "strong" + }, + { + "index": 14, + "title": "Embedding a Gist", + "startSegmentIndex": 125, + "score": "strong" + }, + { + "index": 15, + "title": "Cloning a Gist", + "startSegmentIndex": 127, + "score": "strong" + }, + { + "index": 16, + "title": "Forking a Gist", + "startSegmentIndex": 130, + "score": "strong" + }, + { + "index": 17, + "title": "Finding Your Gists", + "startSegmentIndex": 135, + "score": "strong" + }, + { + "index": 18, + "title": "Discovering Public Gists", + "startSegmentIndex": 141, + "score": "strong" + }, + { + "index": 19, + "title": "Gist Comments", + "startSegmentIndex": 144, + "score": "strong" + }, + { + "index": 20, + "title": "Gists vs GitHub Repositories - Quick Comparison", + "startSegmentIndex": 167, + "score": "strong" + }, + { + "index": 21, + "title": "Deleting a Gist", + "startSegmentIndex": 170, + "score": "strong" + }, + { + "index": 22, + "title": "GitHub Discussions: Wrap-Up", + "startSegmentIndex": 174, + "score": "strong" + } + ] + }, + { + "slug": "ep25-releases-tags-insights", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep25-releases-tags-insights-chapters.json", + "chapterCount": 20, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Releases, Tags, and Insights: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Understanding Versioned Releases and Repository Activity", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. What Is a Release?", + "startSegmentIndex": 22, + "score": "strong" + }, + { + "index": 4, + "title": "2. Releases vs. Tags vs. Branches", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 5, + "title": "4. Understanding Version Numbers", + "startSegmentIndex": 40, + "score": "strong" + }, + { + "index": 6, + "title": "5. Reading Release Notes", + "startSegmentIndex": 44, + "score": "strong" + }, + { + "index": 7, + "title": "6. For Maintainers: Creating a Release", + "startSegmentIndex": 48, + "score": "strong" + }, + { + "index": 8, + "title": "7. Draft and Pre-Release States", + "startSegmentIndex": 62, + "score": "strong" + }, + { + "index": 9, + "title": "8. Accessibility Agents: /draft-release", + "startSegmentIndex": 64, + "score": "strong" + }, + { + "index": 10, + "title": "9. What Is the Insights Tab?", + "startSegmentIndex": 74, + "score": "strong" + }, + { + "index": 11, + "title": "10. Navigating to Insights", + "startSegmentIndex": 84, + "score": "strong" + }, + { + "index": 12, + "title": "11. Pulse - Recent Activity Summary", + "startSegmentIndex": 88, + "score": "strong" + }, + { + "index": 13, + "title": "12. Contributors - Who Builds the Project", + "startSegmentIndex": 97, + "score": "strong" + }, + { + "index": 14, + "title": "13. Traffic - Who Visits the Repo", + "startSegmentIndex": 110, + "score": "strong" + }, + { + "index": 15, + "title": "14. Commits and Code Frequency", + "startSegmentIndex": 117, + "score": "strong" + }, + { + "index": 16, + "title": "15. Dependency Graph", + "startSegmentIndex": 120, + "score": "strong" + }, + { + "index": 17, + "title": "16. Network and Forks", + "startSegmentIndex": 126, + "score": "strong" + }, + { + "index": 18, + "title": "17. Community Standards", + "startSegmentIndex": 129, + "score": "strong" + }, + { + "index": 19, + "title": "19. Accessibility Agents: /my-stats and /team-dashboard", + "startSegmentIndex": 139, + "score": "strong" + }, + { + "index": 20, + "title": "Releases, Tags, and Insights: Wrap-Up", + "startSegmentIndex": 147, + "score": "strong" + } + ] + }, + { + "slug": "ep26-github-projects", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep26-github-projects-chapters.json", + "chapterCount": 11, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Projects Deep Dive: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Boards, Tables, Roadmaps, Automations, and Accessible Navigation", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Projects v2: What Changed", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "2. Creating a Project", + "startSegmentIndex": 10, + "score": "strong" + }, + { + "index": 5, + "title": "4. Custom Fields", + "startSegmentIndex": 49, + "score": "strong" + }, + { + "index": 6, + "title": "6. Built-In Automations", + "startSegmentIndex": 79, + "score": "strong" + }, + { + "index": 7, + "title": "7. Iterations (Sprints)", + "startSegmentIndex": 92, + "score": "strong" + }, + { + "index": 8, + "title": "8. Views and Filters", + "startSegmentIndex": 109, + "score": "strong" + }, + { + "index": 9, + "title": "9. Cross-Repository Projects", + "startSegmentIndex": 125, + "score": "strong" + }, + { + "index": 10, + "title": "11. Accessibility Agents: /project-status", + "startSegmentIndex": 138, + "score": "strong" + }, + { + "index": 11, + "title": "GitHub Projects Deep Dive: Wrap-Up", + "startSegmentIndex": 164, + "score": "strong" + } + ] + }, + { + "slug": "ep27-advanced-search", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep27-advanced-search-chapters.json", + "chapterCount": 8, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Advanced Search: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Finding Anything Across All of GitHub", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. The Search Interface", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "2. Search Scopes", + "startSegmentIndex": 17, + "score": "strong" + }, + { + "index": 5, + "title": "5. Searching Code", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 6, + "title": "9. Practical Queries for This Workshop", + "startSegmentIndex": 25, + "score": "strong" + }, + { + "index": 7, + "title": "10. Saving and Reusing Searches", + "startSegmentIndex": 28, + "score": "strong" + }, + { + "index": 8, + "title": "Advanced Search: Wrap-Up", + "startSegmentIndex": 34, + "score": "strong" + } + ] + }, + { + "slug": "ep28-branch-protection", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep28-branch-protection-chapters.json", + "chapterCount": 11, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Branch Protection and Rulesets: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "How Merging Rules Work and Why Your PR May Be Blocked", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. What Branch Protection Does", + "startSegmentIndex": 14, + "score": "strong" + }, + { + "index": 4, + "title": "3. Repository Rulesets - The Modern Approach", + "startSegmentIndex": 40, + "score": "strong" + }, + { + "index": 5, + "title": "4. Why Your PR Cannot Be Merged - Diagnosis Guide", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 6, + "title": "5. Navigating the Merge Box with a Screen Reader", + "startSegmentIndex": 80, + "score": "strong" + }, + { + "index": 7, + "title": "6. Status Checks - What They Are and What They Mean", + "startSegmentIndex": 84, + "score": "strong" + }, + { + "index": 8, + "title": "7. Who Can Configure Branch Protection", + "startSegmentIndex": 91, + "score": "strong" + }, + { + "index": 9, + "title": "8. Workshop Repository Configuration Reference", + "startSegmentIndex": 93, + "score": "strong" + }, + { + "index": 10, + "title": "Related Resources", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 11, + "title": "Branch Protection and Rulesets: Wrap-Up", + "startSegmentIndex": 100, + "score": "strong" + } + ] + }, + { + "slug": "ep29-security-features", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep29-security-features-chapters.json", + "chapterCount": 11, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Security Features: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Dependabot, Secret Scanning, Code Scanning, and Private.", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. The Security and quality tab - What It Contains", + "startSegmentIndex": 14, + "score": "strong" + }, + { + "index": 4, + "title": "2. Dependabot - Automated Dependency Updates", + "startSegmentIndex": 27, + "score": "strong" + }, + { + "index": 5, + "title": "3. Secret Scanning - Preventing Credential Leaks", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 6, + "title": "4. Code Scanning and CodeQL", + "startSegmentIndex": 53, + "score": "strong" + }, + { + "index": 7, + "title": "5. Private Vulnerability Reporting", + "startSegmentIndex": 62, + "score": "strong" + }, + { + "index": 8, + "title": "6. The SECURITY.md File", + "startSegmentIndex": 78, + "score": "strong" + }, + { + "index": 9, + "title": "7. Software Bill of Materials (SBOM)", + "startSegmentIndex": 85, + "score": "strong" + }, + { + "index": 10, + "title": "9. Security and Accessibility Agents", + "startSegmentIndex": 91, + "score": "strong" + }, + { + "index": 11, + "title": "GitHub Security Features: Wrap-Up", + "startSegmentIndex": 97, + "score": "strong" + } + ] + }, + { + "slug": "ep30-vscode-accessibility-reference", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep30-vscode-accessibility-reference-chapters.json", + "chapterCount": 9, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "VS Code Accessibility Reference: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Complete Technical Reference for Screen Reader Users", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Complete Accessibility Settings Reference", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "2. Audio Cues - All Options", + "startSegmentIndex": 16, + "score": "strong" + }, + { + "index": 5, + "title": "3. Accessible Diff Viewer - Complete Guide", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 6, + "title": "5. Complete Keyboard Shortcuts", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 7, + "title": "6. Accessibility Signals Types and Customization", + "startSegmentIndex": 88, + "score": "strong" + }, + { + "index": 8, + "title": "7. Settings.json Configuration Examples", + "startSegmentIndex": 101, + "score": "strong" + }, + { + "index": 9, + "title": "VS Code Accessibility Reference: Wrap-Up", + "startSegmentIndex": 109, + "score": "strong" + } + ] + }, + { + "slug": "ep31-github-codespaces", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep31-github-codespaces-chapters.json", + "chapterCount": 7, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Codespaces: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Cloud Development Environments - Accessibility Guide", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. What Is GitHub Codespaces?", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "6. Keyboard Shortcuts in Codespaces", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 5, + "title": "8. Dotfiles and Persistent Configuration", + "startSegmentIndex": 77, + "score": "strong" + }, + { + "index": 6, + "title": "9. Codespaces vs GitHub.dev", + "startSegmentIndex": 81, + "score": "strong" + }, + { + "index": 7, + "title": "GitHub Codespaces: Wrap-Up", + "startSegmentIndex": 101, + "score": "strong" + } + ] + }, + { + "slug": "ep32-github-mobile", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep32-github-mobile-chapters.json", + "chapterCount": 8, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Mobile: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Accessibility Guide for iOS and Android", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Installing GitHub Mobile", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "2. Getting Around the App", + "startSegmentIndex": 16, + "score": "strong" + }, + { + "index": 5, + "title": "5. Working with Notifications", + "startSegmentIndex": 37, + "score": "strong" + }, + { + "index": 6, + "title": "6. Reviewing Pull Requests", + "startSegmentIndex": 49, + "score": "strong" + }, + { + "index": 7, + "title": "8. What Mobile Does Well vs. Desktop", + "startSegmentIndex": 70, + "score": "strong" + }, + { + "index": 8, + "title": "GitHub Mobile: Wrap-Up", + "startSegmentIndex": 84, + "score": "strong" + } + ] + }, + { + "slug": "ep33-github-pages", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep33-github-pages-chapters.json", + "chapterCount": 10, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Publishing with GitHub Pages: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "How to Deploy a Static Website Directly from Your Repository", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. What GitHub Pages Is", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "4. The html/ Folder in This Project", + "startSegmentIndex": 35, + "score": "strong" + }, + { + "index": 5, + "title": "Option A2 - Rename html/ to docs/", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 6, + "title": "5. Custom Domains", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 7, + "title": "6. HTTPS and Security", + "startSegmentIndex": 58, + "score": "strong" + }, + { + "index": 8, + "title": "7. Accessibility Considerations for Published Sites", + "startSegmentIndex": 64, + "score": "strong" + }, + { + "index": 9, + "title": "8. GitHub Actions and Continuous Deployment", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 10, + "title": "Publishing with GitHub Pages: Wrap-Up", + "startSegmentIndex": 103, + "score": "strong" + } + ] + }, + { + "slug": "ep34-github-actions", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep34-github-actions-chapters.json", + "chapterCount": 13, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Actions and Workflows: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Understanding Automation in Open Source Repositories", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. What Is GitHub Actions?", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "3. Where Workflows Live in a Repository", + "startSegmentIndex": 16, + "score": "strong" + }, + { + "index": 5, + "title": "4. The Anatomy of a Workflow File", + "startSegmentIndex": 20, + "score": "strong" + }, + { + "index": 6, + "title": "5. What Triggers a Workflow", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 7, + "title": "6. Understanding Status Checks on Pull Requests", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 8, + "title": "7. Reading the Actions Tab with a Screen Reader", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 9, + "title": "8. Common Workflows You Will Encounter", + "startSegmentIndex": 57, + "score": "strong" + }, + { + "index": 10, + "title": "11. Accessibility-Focused Workflows", + "startSegmentIndex": 106, + "score": "strong" + }, + { + "index": 11, + "title": "13. What We Are NOT Covering (And Where to Learn More)", + "startSegmentIndex": 127, + "score": "strong" + }, + { + "index": 12, + "title": "Summary", + "startSegmentIndex": 130, + "score": "strong" + }, + { + "index": 13, + "title": "GitHub Actions and Workflows: Wrap-Up", + "startSegmentIndex": 133, + "score": "strong" + } + ] + }, + { + "slug": "ep35-profile-sponsors-wikis", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep35-profile-sponsors-wikis-chapters.json", + "chapterCount": 13, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Profile, Sponsors, and Wikis: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Building Your Community Presence on GitHub", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Repository Settings - What Contributors Need to Know", + "startSegmentIndex": 121, + "score": "strong" + }, + { + "index": 4, + "title": "GitHub Is More Than a Code Host -- It's a Community", + "startSegmentIndex": 133, + "score": "strong" + }, + { + "index": 5, + "title": "4. Your Home Feed -- What You See When You Log In", + "startSegmentIndex": 186, + "score": "strong" + }, + { + "index": 6, + "title": "5. GitHub Explore -- Discovering New Projects", + "startSegmentIndex": 195, + "score": "strong" + }, + { + "index": 7, + "title": "6. Trending -- What's Popular Right Now", + "startSegmentIndex": 205, + "score": "strong" + }, + { + "index": 8, + "title": "7. Topics -- Finding Projects by Category", + "startSegmentIndex": 213, + "score": "strong" + }, + { + "index": 9, + "title": "8. GitHub Lists -- Organizing Your Stars", + "startSegmentIndex": 219, + "score": "strong" + }, + { + "index": 10, + "title": "9. Finding Accessible and Inclusive Projects", + "startSegmentIndex": 233, + "score": "strong" + }, + { + "index": 11, + "title": "10. Building Your Own Presence", + "startSegmentIndex": 244, + "score": "strong" + }, + { + "index": 12, + "title": "11. The GitHub CLI for Social Features", + "startSegmentIndex": 257, + "score": "strong" + }, + { + "index": 13, + "title": "Profile, Sponsors, and Wikis: Wrap-Up", + "startSegmentIndex": 279, + "score": "strong" + } + ] + }, + { + "slug": "ep36-organizations-templates", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep36-organizations-templates-chapters.json", + "chapterCount": 13, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Organizations and Templates: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Building Your Community Presence on GitHub", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Repository Settings - What Contributors Need to Know", + "startSegmentIndex": 121, + "score": "strong" + }, + { + "index": 4, + "title": "GitHub Is More Than a Code Host -- It's a Community", + "startSegmentIndex": 133, + "score": "strong" + }, + { + "index": 5, + "title": "4. Your Home Feed -- What You See When You Log In", + "startSegmentIndex": 186, + "score": "strong" + }, + { + "index": 6, + "title": "5. GitHub Explore -- Discovering New Projects", + "startSegmentIndex": 195, + "score": "strong" + }, + { + "index": 7, + "title": "6. Trending -- What's Popular Right Now", + "startSegmentIndex": 205, + "score": "strong" + }, + { + "index": 8, + "title": "7. Topics -- Finding Projects by Category", + "startSegmentIndex": 213, + "score": "strong" + }, + { + "index": 9, + "title": "8. GitHub Lists -- Organizing Your Stars", + "startSegmentIndex": 219, + "score": "strong" + }, + { + "index": 10, + "title": "9. Finding Accessible and Inclusive Projects", + "startSegmentIndex": 233, + "score": "strong" + }, + { + "index": 11, + "title": "10. Building Your Own Presence", + "startSegmentIndex": 244, + "score": "strong" + }, + { + "index": 12, + "title": "11. The GitHub CLI for Social Features", + "startSegmentIndex": 257, + "score": "strong" + }, + { + "index": 13, + "title": "Organizations and Templates: Wrap-Up", + "startSegmentIndex": 279, + "score": "strong" + } + ] + }, + { + "slug": "ep37-contributing-to-open-source", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep37-contributing-to-open-source-chapters.json", + "chapterCount": 26, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Contributing to Open Source: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "How to Be an Effective and Respectful Open Source Contributor", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Why Issues Matter", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 4, + "title": "GitHub Flow - The Standard Contribution Workflow", + "startSegmentIndex": 40, + "score": "strong" + }, + { + "index": 5, + "title": "Keeping Your Fork Up to Date", + "startSegmentIndex": 69, + "score": "strong" + }, + { + "index": 6, + "title": "When to sync", + "startSegmentIndex": 90, + "score": "strong" + }, + { + "index": 7, + "title": "Writing Good Commit Messages", + "startSegmentIndex": 102, + "score": "strong" + }, + { + "index": 8, + "title": "The Nature of Open Source Communication", + "startSegmentIndex": 125, + "score": "strong" + }, + { + "index": 9, + "title": "The Anatomy of Helpful Feedback", + "startSegmentIndex": 137, + "score": "strong" + }, + { + "index": 10, + "title": "Inclusive Commenting for Accessibility Issues", + "startSegmentIndex": 201, + "score": "strong" + }, + { + "index": 11, + "title": "The \"Good First Issue\" Social Contract", + "startSegmentIndex": 204, + "score": "strong" + }, + { + "index": 12, + "title": "Writing Your First README", + "startSegmentIndex": 224, + "score": "strong" + }, + { + "index": 13, + "title": "Community Health Files", + "startSegmentIndex": 236, + "score": "strong" + }, + { + "index": 14, + "title": "When to Use Different Communication Channels", + "startSegmentIndex": 252, + "score": "strong" + }, + { + "index": 15, + "title": "Rewrite One Comment", + "startSegmentIndex": 255, + "score": "strong" + }, + { + "index": 16, + "title": "Contributing to Open Source", + "startSegmentIndex": 261, + "score": "strong" + }, + { + "index": 17, + "title": "A Guide for First-Time Contributors", + "startSegmentIndex": 263, + "score": "strong" + }, + { + "index": 18, + "title": "1. What Is Open Source?", + "startSegmentIndex": 264, + "score": "strong" + }, + { + "index": 19, + "title": "2. Who Can Contribute?", + "startSegmentIndex": 268, + "score": "strong" + }, + { + "index": 20, + "title": "3. What Makes a Good First Contribution?", + "startSegmentIndex": 269, + "score": "strong" + }, + { + "index": 21, + "title": "4. Finding Something to Work On", + "startSegmentIndex": 275, + "score": "strong" + }, + { + "index": 22, + "title": "5. Reading an Issue Before You Start", + "startSegmentIndex": 279, + "score": "strong" + }, + { + "index": 23, + "title": "7. Getting Help", + "startSegmentIndex": 297, + "score": "strong" + }, + { + "index": 24, + "title": "8. After Your Contribution Is Merged", + "startSegmentIndex": 300, + "score": "strong" + }, + { + "index": 25, + "title": "9. Building a Contribution Habit", + "startSegmentIndex": 302, + "score": "strong" + }, + { + "index": 26, + "title": "Contributing to Open Source: Wrap-Up", + "startSegmentIndex": 308, + "score": "strong" + } + ] + }, + { + "slug": "ep38-resources", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep38-resources-chapters.json", + "chapterCount": 15, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Resources and Links: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Everything You Need - Before, During, and After the Workshop", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. The Central Project - Accessibility Agents", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "2. GitHub Accessibility Guides", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 5, + "title": "3. GitHub Skills Learning Modules", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 6, + "title": "7. GitHub Agentic Workflows", + "startSegmentIndex": 54, + "score": "strong" + }, + { + "index": 7, + "title": "8. Spec-Driven Development - Spec Kit", + "startSegmentIndex": 62, + "score": "strong" + }, + { + "index": 8, + "title": "10. GitHub Mobile Apps", + "startSegmentIndex": 73, + "score": "strong" + }, + { + "index": 9, + "title": "11. GitHub Best Practices and Power Features", + "startSegmentIndex": 83, + "score": "strong" + }, + { + "index": 10, + "title": "How it works", + "startSegmentIndex": 153, + "score": "strong" + }, + { + "index": 11, + "title": "Use for", + "startSegmentIndex": 157, + "score": "strong" + }, + { + "index": 12, + "title": "12. Finding More Contributions", + "startSegmentIndex": 174, + "score": "strong" + }, + { + "index": 13, + "title": "14b. Learning Pathways", + "startSegmentIndex": 176, + "score": "strong" + }, + { + "index": 14, + "title": "16. Your Workshop Documentation - Offline Reference", + "startSegmentIndex": 178, + "score": "strong" + }, + { + "index": 15, + "title": "Resources and Links: Wrap-Up", + "startSegmentIndex": 183, + "score": "strong" + } + ] + }, + { + "slug": "ep39-accessibility-agents-reference", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep39-accessibility-agents-reference-chapters.json", + "chapterCount": 15, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Accessibility Agents - Complete Reference: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Complete Reference - Agents, Slash Commands, Instructions,.", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. The Full Agent Ecosystem", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "2. GitHub Workflow Agents - Quick Reference", + "startSegmentIndex": 16, + "score": "strong" + }, + { + "index": 5, + "title": "3. Slash Commands and Prompts", + "startSegmentIndex": 43, + "score": "strong" + }, + { + "index": 6, + "title": "4. Customization Primitives - Decision Guide", + "startSegmentIndex": 46, + "score": "strong" + }, + { + "index": 7, + "title": "5. Scope and Priority - All Levels", + "startSegmentIndex": 64, + "score": "strong" + }, + { + "index": 8, + "title": "6. Always-On Instructions - All File Types", + "startSegmentIndex": 76, + "score": "strong" + }, + { + "index": 9, + "title": "7. File-Based Instructions (.instructions.md)", + "startSegmentIndex": 95, + "score": "strong" + }, + { + "index": 10, + "title": "[Section Header]", + "startSegmentIndex": 112, + "score": "strong" + }, + { + "index": 11, + "title": "10. Agent Skills (SKILL.md) - Complete Format Reference", + "startSegmentIndex": 138, + "score": "strong" + }, + { + "index": 12, + "title": "11. Hooks (.json) - Lifecycle Automation", + "startSegmentIndex": 144, + "score": "strong" + }, + { + "index": 13, + "title": "12. preferences.md - Accessibility Agents Personal Settings", + "startSegmentIndex": 158, + "score": "strong" + }, + { + "index": 14, + "title": "14. Further Reading", + "startSegmentIndex": 190, + "score": "strong" + }, + { + "index": 15, + "title": "Accessibility Agents - Complete Reference: Wrap-Up", + "startSegmentIndex": 194, + "score": "strong" + } + ] + }, + { + "slug": "ep40-copilot-reference", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep40-copilot-reference-chapters.json", + "chapterCount": 24, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Copilot - Complete Reference: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Keyboard Shortcuts, Chat, Screen Reader Workflow, Plugin.", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. Chat Participants", + "startSegmentIndex": 15, + "score": "strong" + }, + { + "index": 4, + "title": "3. Chat Slash Commands", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 5, + "title": "4. Chat Modes", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 6, + "title": "5. Custom Instructions - All Levels", + "startSegmentIndex": 30, + "score": "strong" + }, + { + "index": 7, + "title": "Create an instructions file", + "startSegmentIndex": 46, + "score": "strong" + }, + { + "index": 8, + "title": "6. Accessible View Workflow", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 9, + "title": "7. Configuration Scope Reference", + "startSegmentIndex": 87, + "score": "strong" + }, + { + "index": 10, + "title": "8. Instruction Priority and Conflicts", + "startSegmentIndex": 98, + "score": "strong" + }, + { + "index": 11, + "title": "10. VS Code Settings Reference", + "startSegmentIndex": 106, + "score": "strong" + }, + { + "index": 12, + "title": "12. Screen Reader Workflow - Official Guide", + "startSegmentIndex": 139, + "score": "strong" + }, + { + "index": 13, + "title": "13. awesome-copilot - Plugin Ecosystem", + "startSegmentIndex": 164, + "score": "strong" + }, + { + "index": 14, + "title": "14. GitHub Agentic Workflows - Agents in the Cloud", + "startSegmentIndex": 178, + "score": "strong" + }, + { + "index": 15, + "title": "Copilot Models", + "startSegmentIndex": 198, + "score": "strong" + }, + { + "index": 16, + "title": "1. Overview", + "startSegmentIndex": 201, + "score": "strong" + }, + { + "index": 17, + "title": "2. How to Choose a Model", + "startSegmentIndex": 203, + "score": "strong" + }, + { + "index": 18, + "title": "3. Current Model and Billing Sources", + "startSegmentIndex": 214, + "score": "strong" + }, + { + "index": 19, + "title": "4. Model Availability by Plan", + "startSegmentIndex": 218, + "score": "strong" + }, + { + "index": 20, + "title": "5. GitHub AI Credits and Usage", + "startSegmentIndex": 223, + "score": "strong" + }, + { + "index": 21, + "title": "7. Auto Model Selection", + "startSegmentIndex": 240, + "score": "strong" + }, + { + "index": 22, + "title": "8. Models Retiring Soon", + "startSegmentIndex": 247, + "score": "strong" + }, + { + "index": 23, + "title": "Related Resources", + "startSegmentIndex": 250, + "score": "strong" + }, + { + "index": 24, + "title": "GitHub Copilot - Complete Reference: Wrap-Up", + "startSegmentIndex": 253, + "score": "strong" + } + ] + }, + { + "slug": "ep41-copilot-models", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep41-copilot-models-chapters.json", + "chapterCount": 24, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Copilot Billing and Models: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Keyboard Shortcuts, Chat, Screen Reader Workflow, Plugin.", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. Chat Participants", + "startSegmentIndex": 15, + "score": "strong" + }, + { + "index": 4, + "title": "3. Chat Slash Commands", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 5, + "title": "4. Chat Modes", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 6, + "title": "5. Custom Instructions - All Levels", + "startSegmentIndex": 30, + "score": "strong" + }, + { + "index": 7, + "title": "Create an instructions file", + "startSegmentIndex": 46, + "score": "strong" + }, + { + "index": 8, + "title": "6. Accessible View Workflow", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 9, + "title": "7. Configuration Scope Reference", + "startSegmentIndex": 87, + "score": "strong" + }, + { + "index": 10, + "title": "8. Instruction Priority and Conflicts", + "startSegmentIndex": 98, + "score": "strong" + }, + { + "index": 11, + "title": "10. VS Code Settings Reference", + "startSegmentIndex": 106, + "score": "strong" + }, + { + "index": 12, + "title": "12. Screen Reader Workflow - Official Guide", + "startSegmentIndex": 139, + "score": "strong" + }, + { + "index": 13, + "title": "13. awesome-copilot - Plugin Ecosystem", + "startSegmentIndex": 164, + "score": "strong" + }, + { + "index": 14, + "title": "14. GitHub Agentic Workflows - Agents in the Cloud", + "startSegmentIndex": 178, + "score": "strong" + }, + { + "index": 15, + "title": "Copilot Models", + "startSegmentIndex": 198, + "score": "strong" + }, + { + "index": 16, + "title": "1. Overview", + "startSegmentIndex": 201, + "score": "strong" + }, + { + "index": 17, + "title": "2. How to Choose a Model", + "startSegmentIndex": 203, + "score": "strong" + }, + { + "index": 18, + "title": "3. Current Model and Billing Sources", + "startSegmentIndex": 214, + "score": "strong" + }, + { + "index": 19, + "title": "4. Model Availability by Plan", + "startSegmentIndex": 218, + "score": "strong" + }, + { + "index": 20, + "title": "5. GitHub AI Credits and Usage", + "startSegmentIndex": 223, + "score": "strong" + }, + { + "index": 21, + "title": "7. Auto Model Selection", + "startSegmentIndex": 240, + "score": "strong" + }, + { + "index": 22, + "title": "8. Models Retiring Soon", + "startSegmentIndex": 247, + "score": "strong" + }, + { + "index": 23, + "title": "Related Resources", + "startSegmentIndex": 250, + "score": "strong" + }, + { + "index": 24, + "title": "Copilot Billing and Models: Wrap-Up", + "startSegmentIndex": 253, + "score": "strong" + } + ] + }, + { + "slug": "ep42-accessing-workshop-materials", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep42-accessing-workshop-materials-chapters.json", + "chapterCount": 8, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Accessing Workshop Materials: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "How to Get, Read, and Keep These Documents", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Browsing Online (GitHub Pages)", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "2. Reading on GitHub.com", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 5, + "title": "4. Downloading Individual Files", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 6, + "title": "6. Offline Reading", + "startSegmentIndex": 46, + "score": "strong" + }, + { + "index": 7, + "title": "8. Which Format Should I Use?", + "startSegmentIndex": 64, + "score": "strong" + }, + { + "index": 8, + "title": "Accessing Workshop Materials: Wrap-Up", + "startSegmentIndex": 74, + "score": "strong" + } + ] + }, + { + "slug": "ep43-github-skills-catalog", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep43-github-skills-catalog-chapters.json", + "chapterCount": 7, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Skills - Complete Course Catalog: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "How GitHub Skills Works", + "startSegmentIndex": 10, + "score": "strong" + }, + { + "index": 3, + "title": "Courses Used in This Workshop", + "startSegmentIndex": 15, + "score": "strong" + }, + { + "index": 4, + "title": "Learning Paths", + "startSegmentIndex": 20, + "score": "strong" + }, + { + "index": 5, + "title": "Quick Reference - All 36 Courses", + "startSegmentIndex": 37, + "score": "strong" + }, + { + "index": 6, + "title": "Additional Resources", + "startSegmentIndex": 52, + "score": "strong" + }, + { + "index": 7, + "title": "GitHub Skills - Complete Course Catalog: Wrap-Up", + "startSegmentIndex": 56, + "score": "strong" + } + ] + }, + { + "slug": "ep50-advanced-git-operations", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep50-advanced-git-operations-chapters.json", + "chapterCount": 14, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Advanced Git Operations: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Going Deeper with Git", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Cherry-Pick -- Grabbing a Specific Commit", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "2. Interactive Rebase -- Cleaning Up Your History", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 5, + "title": "3. git reset -- Undoing at Different Depths", + "startSegmentIndex": 62, + "score": "strong" + }, + { + "index": 6, + "title": "4. git revert -- The Safe Undo for Shared Branches", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 7, + "title": "5. Tags -- Marking Important Moments", + "startSegmentIndex": 98, + "score": "strong" + }, + { + "index": 8, + "title": "6. Detached HEAD -- What It Is and How to Get Out", + "startSegmentIndex": 118, + "score": "strong" + }, + { + "index": 9, + "title": "7. Force Pushing Safely", + "startSegmentIndex": 133, + "score": "strong" + }, + { + "index": 10, + "title": "8. git bisect -- Finding the Commit That Broke Things", + "startSegmentIndex": 150, + "score": "strong" + }, + { + "index": 11, + "title": "9. git clean -- Clearing Out Untracked Files", + "startSegmentIndex": 163, + "score": "strong" + }, + { + "index": 12, + "title": "10. Branch Protection -- Why Your Push or Merge May Be Blocked", + "startSegmentIndex": 176, + "score": "strong" + }, + { + "index": 13, + "title": "11. Using GitHub Copilot for Git Operations", + "startSegmentIndex": 198, + "score": "strong" + }, + { + "index": 14, + "title": "Advanced Git Operations: Wrap-Up", + "startSegmentIndex": 220, + "score": "strong" + } + ] + }, + { + "slug": "ep51-git-security-for-contributors", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep51-git-security-for-contributors-chapters.json", + "chapterCount": 10, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Git Security for Contributors: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Keeping Secrets Out of Your Repository", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. Why This Matters -- What Happens When Secrets Leak", + "startSegmentIndex": 11, + "score": "strong" + }, + { + "index": 4, + "title": "2. The.gitignore File -- Your First Line of Defense", + "startSegmentIndex": 17, + "score": "strong" + }, + { + "index": 5, + "title": "3. Environment Variables -- The Right Way to Store Secrets", + "startSegmentIndex": 28, + "score": "strong" + }, + { + "index": 6, + "title": "4. Review Before You Commit", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 7, + "title": "5. Pre-Commit Hooks -- Automated Secret Detection", + "startSegmentIndex": 51, + "score": "strong" + }, + { + "index": 8, + "title": "7. GitHub's Built-In Push Protection", + "startSegmentIndex": 76, + "score": "strong" + }, + { + "index": 9, + "title": "9. Security Checklist for Contributors", + "startSegmentIndex": 101, + "score": "strong" + }, + { + "index": 10, + "title": "Git Security for Contributors: Wrap-Up", + "startSegmentIndex": 116, + "score": "strong" + } + ] + }, + { + "slug": "ep52-github-desktop", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep52-github-desktop-chapters.json", + "chapterCount": 14, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub Desktop: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "A Visual Git Client for Every Workflow", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "1. What GitHub Desktop Does (and Doesn't Do)", + "startSegmentIndex": 9, + "score": "strong" + }, + { + "index": 4, + "title": "3. Signing In and Authentication", + "startSegmentIndex": 28, + "score": "strong" + }, + { + "index": 5, + "title": "4. The Interface at a Glance", + "startSegmentIndex": 37, + "score": "strong" + }, + { + "index": 6, + "title": "8. Push and Pull", + "startSegmentIndex": 82, + "score": "strong" + }, + { + "index": 7, + "title": "9. Syncing Your Fork", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 8, + "title": "10. Resolving Merge Conflicts", + "startSegmentIndex": 104, + "score": "strong" + }, + { + "index": 9, + "title": "11. Viewing History", + "startSegmentIndex": 115, + "score": "strong" + }, + { + "index": 10, + "title": "12. Cherry-Pick in GitHub Desktop", + "startSegmentIndex": 131, + "score": "strong" + }, + { + "index": 11, + "title": "13. Stashing Changes", + "startSegmentIndex": 141, + "score": "strong" + }, + { + "index": 12, + "title": "15. Accessibility and Screen Reader Notes", + "startSegmentIndex": 158, + "score": "strong" + }, + { + "index": 13, + "title": "16. GitHub Desktop vs VS Code vs Git CLI -- When to Use Each", + "startSegmentIndex": 171, + "score": "strong" + }, + { + "index": 14, + "title": "GitHub Desktop: Wrap-Up", + "startSegmentIndex": 175, + "score": "strong" + } + ] + }, + { + "slug": "ep53-github-cli-reference", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep53-github-cli-reference-chapters.json", + "chapterCount": 11, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "GitHub CLI Reference: Overview", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Your Terminal, Supercharged for GitHub", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "2. Repos -- Clone, Fork, Create, View", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 4, + "title": "5. Releases -- Create, List, Upload", + "startSegmentIndex": 67, + "score": "strong" + }, + { + "index": 5, + "title": "6. Search -- Issues, PRs, Repos, Code", + "startSegmentIndex": 73, + "score": "strong" + }, + { + "index": 6, + "title": "8. Output Formatting -- JSON, jq, Templates", + "startSegmentIndex": 83, + "score": "strong" + }, + { + "index": 7, + "title": "9. Aliases -- Create Your Own Shortcuts", + "startSegmentIndex": 98, + "score": "strong" + }, + { + "index": 8, + "title": "10. Extensions -- Adding New Commands", + "startSegmentIndex": 107, + "score": "strong" + }, + { + "index": 9, + "title": "11. Copilot in the CLI", + "startSegmentIndex": 110, + "score": "strong" + }, + { + "index": 10, + "title": "12. Screen Reader Tips", + "startSegmentIndex": 120, + "score": "strong" + }, + { + "index": 11, + "title": "GitHub CLI Reference: Wrap-Up", + "startSegmentIndex": 143, + "score": "strong" + } + ] + }, + { + "slug": "cc-01-find-your-way-around", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-01-find-your-way-around-chapters.json", + "chapterCount": 46, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 01: Find Your Way Around", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 1: Find Your Way Around", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Alternate approaches", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 4, + "title": "What matters", + "startSegmentIndex": 35, + "score": "strong" + }, + { + "index": 5, + "title": "How GitHub Is Organized, and How to Orient Yourself on Every.", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 6, + "title": "1. GitHub's Three-Level Structure", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 7, + "title": "2. What Is Always on Every GitHub Page", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 8, + "title": "3. How to Tell Where You Are", + "startSegmentIndex": 52, + "score": "strong" + }, + { + "index": 9, + "title": "5. Visual Map of a Repository Page", + "startSegmentIndex": 91, + "score": "strong" + }, + { + "index": 10, + "title": "6. Screen Reader Orientation Sequence", + "startSegmentIndex": 98, + "score": "strong" + }, + { + "index": 11, + "title": "7. Landmark Structure by Page Type", + "startSegmentIndex": 107, + "score": "strong" + }, + { + "index": 12, + "title": "8. GitHub's Heading Hierarchy in Practice", + "startSegmentIndex": 109, + "score": "strong" + }, + { + "index": 13, + "title": "9. How GitHub's Layout Changes by Viewport", + "startSegmentIndex": 117, + "score": "strong" + }, + { + "index": 14, + "title": "10. The Mental Model - Building Your Internal Map", + "startSegmentIndex": 127, + "score": "strong" + }, + { + "index": 15, + "title": "The 60-Second Orientation", + "startSegmentIndex": 133, + "score": "strong" + }, + { + "index": 16, + "title": "Day 2 Amplifier", + "startSegmentIndex": 136, + "score": "strong" + }, + { + "index": 17, + "title": "A Screen Reader Guide to GitHub Repositories", + "startSegmentIndex": 138, + "score": "strong" + }, + { + "index": 18, + "title": "What Is a Repository Page?", + "startSegmentIndex": 147, + "score": "strong" + }, + { + "index": 19, + "title": "Landing on a Repository - What to Expect", + "startSegmentIndex": 151, + "score": "strong" + }, + { + "index": 20, + "title": "Navigating the Repository Tabs", + "startSegmentIndex": 157, + "score": "strong" + }, + { + "index": 21, + "title": "The Files Table", + "startSegmentIndex": 166, + "score": "strong" + }, + { + "index": 22, + "title": "The Branch Selector", + "startSegmentIndex": 179, + "score": "strong" + }, + { + "index": 23, + "title": "Cloning a Repository", + "startSegmentIndex": 195, + "score": "strong" + }, + { + "index": 24, + "title": "Or with standard Git", + "startSegmentIndex": 202, + "score": "strong" + }, + { + "index": 25, + "title": "Fork vs. Clone vs. Branch - What Is the Difference?", + "startSegmentIndex": 215, + "score": "strong" + }, + { + "index": 26, + "title": "Watching, Starring, and Forking", + "startSegmentIndex": 219, + "score": "strong" + }, + { + "index": 27, + "title": "Viewing a Single File", + "startSegmentIndex": 236, + "score": "strong" + }, + { + "index": 28, + "title": "The Blame View", + "startSegmentIndex": 256, + "score": "strong" + }, + { + "index": 29, + "title": "Commit History", + "startSegmentIndex": 261, + "score": "strong" + }, + { + "index": 30, + "title": "Searching for a File", + "startSegmentIndex": 269, + "score": "strong" + }, + { + "index": 31, + "title": "GitHub Shortcuts for Repository Navigation - Spotlight", + "startSegmentIndex": 279, + "score": "strong" + }, + { + "index": 32, + "title": "The Repository About Section", + "startSegmentIndex": 283, + "score": "strong" + }, + { + "index": 33, + "title": "The Five-Tab Tour", + "startSegmentIndex": 303, + "score": "strong" + }, + { + "index": 34, + "title": "What Is the Learning Room?", + "startSegmentIndex": 309, + "score": "strong" + }, + { + "index": 35, + "title": "Why a Per-Student Repo?", + "startSegmentIndex": 311, + "score": "strong" + }, + { + "index": 36, + "title": "Step-by-Step: Accept Your Classroom Assignment and Open Your.", + "startSegmentIndex": 313, + "score": "strong" + }, + { + "index": 37, + "title": "Two Tracks That Reinforce Each Other", + "startSegmentIndex": 341, + "score": "strong" + }, + { + "index": 38, + "title": "Your Learning Room Folder Structure", + "startSegmentIndex": 354, + "score": "strong" + }, + { + "index": 39, + "title": "Your Practice Branch", + "startSegmentIndex": 357, + "score": "strong" + }, + { + "index": 40, + "title": "The Practice Files: What You Will Work On", + "startSegmentIndex": 376, + "score": "strong" + }, + { + "index": 41, + "title": "The Learning Automation System", + "startSegmentIndex": 438, + "score": "strong" + }, + { + "index": 42, + "title": "Study Groups (Optional)", + "startSegmentIndex": 448, + "score": "strong" + }, + { + "index": 43, + "title": "Key Differences: Skills Module vs. Your Learning Room", + "startSegmentIndex": 452, + "score": "strong" + }, + { + "index": 44, + "title": "Tips for Reviewing a Peer's PR", + "startSegmentIndex": 455, + "score": "strong" + }, + { + "index": 45, + "title": "Celebration: You're Contributing", + "startSegmentIndex": 496, + "score": "strong" + }, + { + "index": 46, + "title": "Find Your Way Around: Final Checkpoint", + "startSegmentIndex": 499, + "score": "strong" + } + ] + }, + { + "slug": "cc-02-file-your-first-issue", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-02-file-your-first-issue-chapters.json", + "chapterCount": 16, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 02: File Your First Issue", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 2: File Your First Issue", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Example 1: Bug report style", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 4, + "title": "Example 2: Feature request style", + "startSegmentIndex": 21, + "score": "strong" + }, + { + "index": 5, + "title": "What makes a good issue", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 6, + "title": "Alternate approaches", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 7, + "title": "Issues as Collaboration", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 8, + "title": "Create Your First Issue", + "startSegmentIndex": 37, + "score": "strong" + }, + { + "index": 9, + "title": "Comment and @Mention", + "startSegmentIndex": 44, + "score": "strong" + }, + { + "index": 10, + "title": "Add a Sub-Issue", + "startSegmentIndex": 52, + "score": "strong" + }, + { + "index": 11, + "title": "Why Issues Matter", + "startSegmentIndex": 68, + "score": "strong" + }, + { + "index": 12, + "title": "Anatomy of a GitHub Issue", + "startSegmentIndex": 82, + "score": "strong" + }, + { + "index": 13, + "title": "Sub-Issue Relationships", + "startSegmentIndex": 210, + "score": "strong" + }, + { + "index": 14, + "title": "Good First Issue", + "startSegmentIndex": 244, + "score": "strong" + }, + { + "index": 15, + "title": "Accessibility Issue Tips", + "startSegmentIndex": 252, + "score": "strong" + }, + { + "index": 16, + "title": "File Your First Issue: Final Checkpoint", + "startSegmentIndex": 285, + "score": "strong" + } + ] + }, + { + "slug": "cc-03-join-the-conversation", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-03-join-the-conversation-chapters.json", + "chapterCount": 39, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 03: Join the Conversation", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 3: Join the Conversation", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "What makes a good comment", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 4, + "title": "Alternate approaches", + "startSegmentIndex": 27, + "score": "strong" + }, + { + "index": 5, + "title": "What matters", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 6, + "title": "Issues as Collaboration", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 7, + "title": "Create Your First Issue", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 8, + "title": "Comment and @Mention", + "startSegmentIndex": 50, + "score": "strong" + }, + { + "index": 9, + "title": "Add a Sub-Issue", + "startSegmentIndex": 56, + "score": "strong" + }, + { + "index": 10, + "title": "Why Issues Matter", + "startSegmentIndex": 75, + "score": "strong" + }, + { + "index": 11, + "title": "Anatomy of a GitHub Issue", + "startSegmentIndex": 88, + "score": "strong" + }, + { + "index": 12, + "title": "Sub-Issue Relationships", + "startSegmentIndex": 219, + "score": "strong" + }, + { + "index": 13, + "title": "Good First Issue", + "startSegmentIndex": 256, + "score": "strong" + }, + { + "index": 14, + "title": "Accessibility Issue Tips", + "startSegmentIndex": 265, + "score": "strong" + }, + { + "index": 15, + "title": "How to Be an Effective and Respectful Open Source Contributor", + "startSegmentIndex": 296, + "score": "strong" + }, + { + "index": 16, + "title": "Why Issues Matter", + "startSegmentIndex": 319, + "score": "strong" + }, + { + "index": 17, + "title": "GitHub Flow - The Standard Contribution Workflow", + "startSegmentIndex": 323, + "score": "strong" + }, + { + "index": 18, + "title": "Keeping Your Fork Up to Date", + "startSegmentIndex": 348, + "score": "strong" + }, + { + "index": 19, + "title": "When to sync", + "startSegmentIndex": 367, + "score": "strong" + }, + { + "index": 20, + "title": "Writing Good Commit Messages", + "startSegmentIndex": 377, + "score": "strong" + }, + { + "index": 21, + "title": "The Nature of Open Source Communication", + "startSegmentIndex": 398, + "score": "strong" + }, + { + "index": 22, + "title": "The Anatomy of Helpful Feedback", + "startSegmentIndex": 408, + "score": "strong" + }, + { + "index": 23, + "title": "Inclusive Commenting for Accessibility Issues", + "startSegmentIndex": 472, + "score": "strong" + }, + { + "index": 24, + "title": "The \"Good First Issue\" Social Contract", + "startSegmentIndex": 475, + "score": "strong" + }, + { + "index": 25, + "title": "Writing Your First README", + "startSegmentIndex": 495, + "score": "strong" + }, + { + "index": 26, + "title": "Community Health Files", + "startSegmentIndex": 507, + "score": "strong" + }, + { + "index": 27, + "title": "When to Use Different Communication Channels", + "startSegmentIndex": 523, + "score": "strong" + }, + { + "index": 28, + "title": "Rewrite One Comment", + "startSegmentIndex": 526, + "score": "strong" + }, + { + "index": 29, + "title": "Contributing to Open Source", + "startSegmentIndex": 532, + "score": "strong" + }, + { + "index": 30, + "title": "A Guide for First-Time Contributors", + "startSegmentIndex": 534, + "score": "strong" + }, + { + "index": 31, + "title": "1. What Is Open Source?", + "startSegmentIndex": 535, + "score": "strong" + }, + { + "index": 32, + "title": "2. Who Can Contribute?", + "startSegmentIndex": 539, + "score": "strong" + }, + { + "index": 33, + "title": "3. What Makes a Good First Contribution?", + "startSegmentIndex": 540, + "score": "strong" + }, + { + "index": 34, + "title": "4. Finding Something to Work On", + "startSegmentIndex": 546, + "score": "strong" + }, + { + "index": 35, + "title": "5. Reading an Issue Before You Start", + "startSegmentIndex": 550, + "score": "strong" + }, + { + "index": 36, + "title": "7. Getting Help", + "startSegmentIndex": 568, + "score": "strong" + }, + { + "index": 37, + "title": "8. After Your Contribution Is Merged", + "startSegmentIndex": 571, + "score": "strong" + }, + { + "index": 38, + "title": "9. Building a Contribution Habit", + "startSegmentIndex": 573, + "score": "strong" + }, + { + "index": 39, + "title": "Join the Conversation: Final Checkpoint", + "startSegmentIndex": 579, + "score": "strong" + } + ] + }, + { + "slug": "cc-04-branch-out", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-04-branch-out-chapters.json", + "chapterCount": 36, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 04: Branch Out", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 4: Branch Out", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "On github.com", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 4, + "title": "In VS Code (with Git)", + "startSegmentIndex": 22, + "score": "strong" + }, + { + "index": 5, + "title": "In GitHub Desktop", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 6, + "title": "With GitHub CLI", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 7, + "title": "Branch naming", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 8, + "title": "What matters", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 9, + "title": "What Is the Learning Room?", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 10, + "title": "Why a Per-Student Repo?", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 11, + "title": "Step-by-Step: Accept Your Classroom Assignment and Open Your.", + "startSegmentIndex": 44, + "score": "strong" + }, + { + "index": 12, + "title": "Two Tracks That Reinforce Each Other", + "startSegmentIndex": 76, + "score": "strong" + }, + { + "index": 13, + "title": "Your Learning Room Folder Structure", + "startSegmentIndex": 90, + "score": "strong" + }, + { + "index": 14, + "title": "Your Practice Branch", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 15, + "title": "The Practice Files: What You Will Work On", + "startSegmentIndex": 114, + "score": "strong" + }, + { + "index": 16, + "title": "The Learning Automation System", + "startSegmentIndex": 180, + "score": "strong" + }, + { + "index": 17, + "title": "Study Groups (Optional)", + "startSegmentIndex": 191, + "score": "strong" + }, + { + "index": 18, + "title": "Key Differences: Skills Module vs. Your Learning Room", + "startSegmentIndex": 194, + "score": "strong" + }, + { + "index": 19, + "title": "Tips for Reviewing a Peer's PR", + "startSegmentIndex": 197, + "score": "strong" + }, + { + "index": 20, + "title": "Celebration: You're Contributing", + "startSegmentIndex": 238, + "score": "strong" + }, + { + "index": 21, + "title": "Creating, Reviewing, and Merging Pull Requests with a Screen.", + "startSegmentIndex": 241, + "score": "strong" + }, + { + "index": 22, + "title": "Why Issues Matter", + "startSegmentIndex": 273, + "score": "strong" + }, + { + "index": 23, + "title": "What Is a Pull Request?", + "startSegmentIndex": 283, + "score": "strong" + }, + { + "index": 24, + "title": "Navigating to Pull Requests", + "startSegmentIndex": 285, + "score": "strong" + }, + { + "index": 25, + "title": "The Pull Request List Page", + "startSegmentIndex": 298, + "score": "strong" + }, + { + "index": 26, + "title": "Navigating the PR Tab Bar", + "startSegmentIndex": 300, + "score": "strong" + }, + { + "index": 27, + "title": "Reading the Checks Tab", + "startSegmentIndex": 324, + "score": "strong" + }, + { + "index": 28, + "title": "Reading the Files Changed Tab", + "startSegmentIndex": 333, + "score": "strong" + }, + { + "index": 29, + "title": "Requesting reviewers", + "startSegmentIndex": 413, + "score": "strong" + }, + { + "index": 30, + "title": "Submitting a Review", + "startSegmentIndex": 418, + "score": "strong" + }, + { + "index": 31, + "title": "Understanding Merge Options (for Maintainers)", + "startSegmentIndex": 464, + "score": "strong" + }, + { + "index": 32, + "title": "After a PR is merged", + "startSegmentIndex": 467, + "score": "strong" + }, + { + "index": 33, + "title": "Auto-Merge - Merging When You Can't Wait Around", + "startSegmentIndex": 470, + "score": "strong" + }, + { + "index": 34, + "title": "Writing PR Descriptions That Get Reviewed", + "startSegmentIndex": 483, + "score": "strong" + }, + { + "index": 35, + "title": "Read a Real Pull Request", + "startSegmentIndex": 501, + "score": "strong" + }, + { + "index": 36, + "title": "Branch Out: Final Checkpoint", + "startSegmentIndex": 507, + "score": "strong" + } + ] + }, + { + "slug": "cc-05-make-your-mark", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-05-make-your-mark-chapters.json", + "chapterCount": 32, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 05: Make Your Mark", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 5: Make Your Mark", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Alternate approaches", + "startSegmentIndex": 25, + "score": "strong" + }, + { + "index": 4, + "title": "What matters", + "startSegmentIndex": 28, + "score": "strong" + }, + { + "index": 5, + "title": "What Is the Learning Room?", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 6, + "title": "Why a Per-Student Repo?", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 7, + "title": "Step-by-Step: Accept Your Classroom Assignment and Open Your.", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 8, + "title": "Two Tracks That Reinforce Each Other", + "startSegmentIndex": 68, + "score": "strong" + }, + { + "index": 9, + "title": "Your Learning Room Folder Structure", + "startSegmentIndex": 83, + "score": "strong" + }, + { + "index": 10, + "title": "Your Practice Branch", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 11, + "title": "The Practice Files: What You Will Work On", + "startSegmentIndex": 107, + "score": "strong" + }, + { + "index": 12, + "title": "The Learning Automation System", + "startSegmentIndex": 173, + "score": "strong" + }, + { + "index": 13, + "title": "Study Groups (Optional)", + "startSegmentIndex": 183, + "score": "strong" + }, + { + "index": 14, + "title": "Key Differences: Skills Module vs. Your Learning Room", + "startSegmentIndex": 186, + "score": "strong" + }, + { + "index": 15, + "title": "Tips for Reviewing a Peer's PR", + "startSegmentIndex": 190, + "score": "strong" + }, + { + "index": 16, + "title": "Celebration: You're Contributing", + "startSegmentIndex": 231, + "score": "strong" + }, + { + "index": 17, + "title": "Creating, Reviewing, and Merging Pull Requests with a Screen.", + "startSegmentIndex": 233, + "score": "strong" + }, + { + "index": 18, + "title": "Why Issues Matter", + "startSegmentIndex": 266, + "score": "strong" + }, + { + "index": 19, + "title": "What Is a Pull Request?", + "startSegmentIndex": 275, + "score": "strong" + }, + { + "index": 20, + "title": "Navigating to Pull Requests", + "startSegmentIndex": 277, + "score": "strong" + }, + { + "index": 21, + "title": "The Pull Request List Page", + "startSegmentIndex": 290, + "score": "strong" + }, + { + "index": 22, + "title": "Navigating the PR Tab Bar", + "startSegmentIndex": 293, + "score": "strong" + }, + { + "index": 23, + "title": "Reading the Checks Tab", + "startSegmentIndex": 317, + "score": "strong" + }, + { + "index": 24, + "title": "Reading the Files Changed Tab", + "startSegmentIndex": 325, + "score": "strong" + }, + { + "index": 25, + "title": "Requesting reviewers", + "startSegmentIndex": 405, + "score": "strong" + }, + { + "index": 26, + "title": "Submitting a Review", + "startSegmentIndex": 411, + "score": "strong" + }, + { + "index": 27, + "title": "Understanding Merge Options (for Maintainers)", + "startSegmentIndex": 456, + "score": "strong" + }, + { + "index": 28, + "title": "After a PR is merged", + "startSegmentIndex": 459, + "score": "strong" + }, + { + "index": 29, + "title": "Auto-Merge - Merging When You Can't Wait Around", + "startSegmentIndex": 463, + "score": "strong" + }, + { + "index": 30, + "title": "Writing PR Descriptions That Get Reviewed", + "startSegmentIndex": 475, + "score": "strong" + }, + { + "index": 31, + "title": "Read a Real Pull Request", + "startSegmentIndex": 493, + "score": "strong" + }, + { + "index": 32, + "title": "Make Your Mark: Final Checkpoint", + "startSegmentIndex": 499, + "score": "strong" + } + ] + }, + { + "slug": "cc-06-open-your-first-pr", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-06-open-your-first-pr-chapters.json", + "chapterCount": 21, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 06: Open Your First Pull Request", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 6: Open Your First Pull Request", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Example PR", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 4, + "title": "Alternate linking syntax", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 5, + "title": "What matters", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 6, + "title": "Creating, Reviewing, and Merging Pull Requests with a Screen.", + "startSegmentIndex": 41, + "score": "strong" + }, + { + "index": 7, + "title": "Why Issues Matter", + "startSegmentIndex": 78, + "score": "strong" + }, + { + "index": 8, + "title": "What Is a Pull Request?", + "startSegmentIndex": 91, + "score": "strong" + }, + { + "index": 9, + "title": "Navigating to Pull Requests", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 10, + "title": "The Pull Request List Page", + "startSegmentIndex": 108, + "score": "strong" + }, + { + "index": 11, + "title": "Navigating the PR Tab Bar", + "startSegmentIndex": 111, + "score": "strong" + }, + { + "index": 12, + "title": "Reading the Checks Tab", + "startSegmentIndex": 139, + "score": "strong" + }, + { + "index": 13, + "title": "Reading the Files Changed Tab", + "startSegmentIndex": 149, + "score": "strong" + }, + { + "index": 14, + "title": "Requesting reviewers", + "startSegmentIndex": 230, + "score": "strong" + }, + { + "index": 15, + "title": "Submitting a Review", + "startSegmentIndex": 235, + "score": "strong" + }, + { + "index": 16, + "title": "Understanding Merge Options (for Maintainers)", + "startSegmentIndex": 281, + "score": "strong" + }, + { + "index": 17, + "title": "After a PR is merged", + "startSegmentIndex": 284, + "score": "strong" + }, + { + "index": 18, + "title": "Auto-Merge - Merging When You Can't Wait Around", + "startSegmentIndex": 286, + "score": "strong" + }, + { + "index": 19, + "title": "Writing PR Descriptions That Get Reviewed", + "startSegmentIndex": 299, + "score": "strong" + }, + { + "index": 20, + "title": "Read a Real Pull Request", + "startSegmentIndex": 316, + "score": "strong" + }, + { + "index": 21, + "title": "Open Your First Pull Request: Final Checkpoint", + "startSegmentIndex": 322, + "score": "strong" + } + ] + }, + { + "slug": "cc-07-survive-a-merge-conflict", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-07-survive-a-merge-conflict-chapters.json", + "chapterCount": 18, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 07: Survive a Merge Conflict", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 7: Survive a Merge Conflict", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "What conflict markers look like", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 4, + "title": "On github.com", + "startSegmentIndex": 27, + "score": "strong" + }, + { + "index": 5, + "title": "In VS Code", + "startSegmentIndex": 32, + "score": "strong" + }, + { + "index": 6, + "title": "What matters", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 7, + "title": "Understanding, Preventing, and Resolving Conflicts", + "startSegmentIndex": 37, + "score": "strong" + }, + { + "index": 8, + "title": "Why Issues Matter", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 9, + "title": "What Is a Merge Conflict?", + "startSegmentIndex": 78, + "score": "strong" + }, + { + "index": 10, + "title": "How to Prevent Conflicts (Prevention is Easier Than Resolution)", + "startSegmentIndex": 80, + "score": "strong" + }, + { + "index": 11, + "title": "Advanced Prevention: Understanding Fast-Forward Merges", + "startSegmentIndex": 108, + "score": "strong" + }, + { + "index": 12, + "title": "When Conflicts Are Actually Good", + "startSegmentIndex": 114, + "score": "strong" + }, + { + "index": 13, + "title": "Conflict Markers - What They Mean", + "startSegmentIndex": 123, + "score": "strong" + }, + { + "index": 14, + "title": "Resolving Conflicts on GitHub (Web Editor)", + "startSegmentIndex": 139, + "score": "strong" + }, + { + "index": 15, + "title": "Resolving Conflicts in VS Code (Day 2)", + "startSegmentIndex": 152, + "score": "strong" + }, + { + "index": 16, + "title": "Reading a Conflict Message from Git (Command Line Reference)", + "startSegmentIndex": 171, + "score": "strong" + }, + { + "index": 17, + "title": "Read a Conflict (Without Fear)", + "startSegmentIndex": 174, + "score": "strong" + }, + { + "index": 18, + "title": "Survive a Merge Conflict: Final Checkpoint", + "startSegmentIndex": 178, + "score": "strong" + } + ] + }, + { + "slug": "cc-08-open-source-culture", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-08-open-source-culture-chapters.json", + "chapterCount": 37, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 08: The Culture Layer", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 8: The Culture Layer", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Example reflection comment", + "startSegmentIndex": 19, + "score": "strong" + }, + { + "index": 4, + "title": "Example triage recommendation", + "startSegmentIndex": 21, + "score": "strong" + }, + { + "index": 5, + "title": "Alternate approaches", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 6, + "title": "What matters", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 7, + "title": "How to Be an Effective and Respectful Open Source Contributor", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 8, + "title": "Why Issues Matter", + "startSegmentIndex": 56, + "score": "strong" + }, + { + "index": 9, + "title": "GitHub Flow - The Standard Contribution Workflow", + "startSegmentIndex": 60, + "score": "strong" + }, + { + "index": 10, + "title": "Keeping Your Fork Up to Date", + "startSegmentIndex": 90, + "score": "strong" + }, + { + "index": 11, + "title": "When to sync", + "startSegmentIndex": 113, + "score": "strong" + }, + { + "index": 12, + "title": "Writing Good Commit Messages", + "startSegmentIndex": 123, + "score": "strong" + }, + { + "index": 13, + "title": "The Nature of Open Source Communication", + "startSegmentIndex": 145, + "score": "strong" + }, + { + "index": 14, + "title": "The Anatomy of Helpful Feedback", + "startSegmentIndex": 156, + "score": "strong" + }, + { + "index": 15, + "title": "Inclusive Commenting for Accessibility Issues", + "startSegmentIndex": 220, + "score": "strong" + }, + { + "index": 16, + "title": "The \"Good First Issue\" Social Contract", + "startSegmentIndex": 223, + "score": "strong" + }, + { + "index": 17, + "title": "Writing Your First README", + "startSegmentIndex": 243, + "score": "strong" + }, + { + "index": 18, + "title": "Community Health Files", + "startSegmentIndex": 254, + "score": "strong" + }, + { + "index": 19, + "title": "When to Use Different Communication Channels", + "startSegmentIndex": 271, + "score": "strong" + }, + { + "index": 20, + "title": "Rewrite One Comment", + "startSegmentIndex": 274, + "score": "strong" + }, + { + "index": 21, + "title": "Contributing to Open Source", + "startSegmentIndex": 279, + "score": "strong" + }, + { + "index": 22, + "title": "A Guide for First-Time Contributors", + "startSegmentIndex": 282, + "score": "strong" + }, + { + "index": 23, + "title": "1. What Is Open Source?", + "startSegmentIndex": 283, + "score": "strong" + }, + { + "index": 24, + "title": "2. Who Can Contribute?", + "startSegmentIndex": 286, + "score": "strong" + }, + { + "index": 25, + "title": "3. What Makes a Good First Contribution?", + "startSegmentIndex": 288, + "score": "strong" + }, + { + "index": 26, + "title": "4. Finding Something to Work On", + "startSegmentIndex": 293, + "score": "strong" + }, + { + "index": 27, + "title": "5. Reading an Issue Before You Start", + "startSegmentIndex": 298, + "score": "strong" + }, + { + "index": 28, + "title": "7. Getting Help", + "startSegmentIndex": 315, + "score": "strong" + }, + { + "index": 29, + "title": "8. After Your Contribution Is Merged", + "startSegmentIndex": 319, + "score": "strong" + }, + { + "index": 30, + "title": "9. Building a Contribution Habit", + "startSegmentIndex": 321, + "score": "strong" + }, + { + "index": 31, + "title": "Organizing Work and Cross-Referencing on GitHub", + "startSegmentIndex": 326, + "score": "strong" + }, + { + "index": 32, + "title": "Why Issues Matter", + "startSegmentIndex": 349, + "score": "strong" + }, + { + "index": 33, + "title": "Cross-References", + "startSegmentIndex": 403, + "score": "strong" + }, + { + "index": 34, + "title": "GitHub Projects", + "startSegmentIndex": 416, + "score": "strong" + }, + { + "index": 35, + "title": "Practical Organization Strategy for the Hackathon", + "startSegmentIndex": 437, + "score": "strong" + }, + { + "index": 36, + "title": "Label and Link", + "startSegmentIndex": 438, + "score": "strong" + }, + { + "index": 37, + "title": "The Culture Layer: Final Checkpoint", + "startSegmentIndex": 442, + "score": "strong" + } + ] + }, + { + "slug": "cc-09-merge-day", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-09-merge-day-chapters.json", + "chapterCount": 34, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 09: Merge Day", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Challenge 9: Merge Day", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "What happens at merge", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 4, + "title": "Example evidence", + "startSegmentIndex": 27, + "score": "strong" + }, + { + "index": 5, + "title": "Alternate approaches", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 6, + "title": "What matters", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 7, + "title": "Creating, Reviewing, and Merging Pull Requests with a Screen.", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 8, + "title": "Why Issues Matter", + "startSegmentIndex": 70, + "score": "strong" + }, + { + "index": 9, + "title": "What Is a Pull Request?", + "startSegmentIndex": 82, + "score": "strong" + }, + { + "index": 10, + "title": "Navigating to Pull Requests", + "startSegmentIndex": 84, + "score": "strong" + }, + { + "index": 11, + "title": "The Pull Request List Page", + "startSegmentIndex": 99, + "score": "strong" + }, + { + "index": 12, + "title": "Navigating the PR Tab Bar", + "startSegmentIndex": 101, + "score": "strong" + }, + { + "index": 13, + "title": "Reading the Checks Tab", + "startSegmentIndex": 127, + "score": "strong" + }, + { + "index": 14, + "title": "Reading the Files Changed Tab", + "startSegmentIndex": 138, + "score": "strong" + }, + { + "index": 15, + "title": "Requesting reviewers", + "startSegmentIndex": 220, + "score": "strong" + }, + { + "index": 16, + "title": "Submitting a Review", + "startSegmentIndex": 225, + "score": "strong" + }, + { + "index": 17, + "title": "Understanding Merge Options (for Maintainers)", + "startSegmentIndex": 271, + "score": "strong" + }, + { + "index": 18, + "title": "After a PR is merged", + "startSegmentIndex": 274, + "score": "strong" + }, + { + "index": 19, + "title": "Auto-Merge - Merging When You Can't Wait Around", + "startSegmentIndex": 277, + "score": "strong" + }, + { + "index": 20, + "title": "Writing PR Descriptions That Get Reviewed", + "startSegmentIndex": 290, + "score": "strong" + }, + { + "index": 21, + "title": "Read a Real Pull Request", + "startSegmentIndex": 308, + "score": "strong" + }, + { + "index": 22, + "title": "Managing Your GitHub Notification Inbox", + "startSegmentIndex": 313, + "score": "strong" + }, + { + "index": 23, + "title": "Why Issues Matter", + "startSegmentIndex": 336, + "score": "strong" + }, + { + "index": 24, + "title": "What Generates a Notification?", + "startSegmentIndex": 342, + "score": "strong" + }, + { + "index": 25, + "title": "Notification Subscription Levels", + "startSegmentIndex": 344, + "score": "strong" + }, + { + "index": 26, + "title": "Inbox Actions - Keyboard Shortcuts", + "startSegmentIndex": 365, + "score": "strong" + }, + { + "index": 27, + "title": "Filtering the Inbox", + "startSegmentIndex": 367, + "score": "strong" + }, + { + "index": 28, + "title": "Notification Settings - Per Your Account", + "startSegmentIndex": 389, + "score": "strong" + }, + { + "index": 29, + "title": "Starring vs. Watching - What Is the Difference?", + "startSegmentIndex": 391, + "score": "strong" + }, + { + "index": 30, + "title": "The GitHub Mobile App - A Reference Note", + "startSegmentIndex": 410, + "score": "strong" + }, + { + "index": 31, + "title": "Tame Your Inbox", + "startSegmentIndex": 412, + "score": "strong" + }, + { + "index": 32, + "title": "What You Accomplished Today", + "startSegmentIndex": 415, + "score": "strong" + }, + { + "index": 33, + "title": "What Day 2 Adds", + "startSegmentIndex": 427, + "score": "strong" + }, + { + "index": 34, + "title": "Merge Day: Final Checkpoint", + "startSegmentIndex": 436, + "score": "strong" + } + ] + }, + { + "slug": "cc-10-go-local", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-10-go-local-chapters.json", + "chapterCount": 32, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 10: Go Local", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Terminal/CLI approach", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 3, + "title": "VS Code approach", + "startSegmentIndex": 27, + "score": "strong" + }, + { + "index": 4, + "title": "GitHub Desktop approach", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 5, + "title": "Verifying success", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 6, + "title": "What matters", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 7, + "title": "1. Why a Mental Model Matters", + "startSegmentIndex": 45, + "score": "strong" + }, + { + "index": 8, + "title": "2. The Three Areas: Working Directory, Staging Area, Repository", + "startSegmentIndex": 46, + "score": "strong" + }, + { + "index": 9, + "title": "3. What Is a Commit?", + "startSegmentIndex": 64, + "score": "strong" + }, + { + "index": 10, + "title": "4. What Is a Branch?", + "startSegmentIndex": 75, + "score": "strong" + }, + { + "index": 11, + "title": "5. Local vs Remote", + "startSegmentIndex": 89, + "score": "strong" + }, + { + "index": 12, + "title": "6. Push, Pull, and Fetch", + "startSegmentIndex": 100, + "score": "strong" + }, + { + "index": 13, + "title": "7. Why Merge Conflicts Happen", + "startSegmentIndex": 115, + "score": "strong" + }, + { + "index": 14, + "title": "8. The Git Timeline", + "startSegmentIndex": 133, + "score": "strong" + }, + { + "index": 15, + "title": "9. Putting It All Together", + "startSegmentIndex": 140, + "score": "strong" + }, + { + "index": 16, + "title": "10. If You Get Stuck", + "startSegmentIndex": 145, + "score": "strong" + }, + { + "index": 17, + "title": "Managing Repositories, Branches, and Changes Accessibly", + "startSegmentIndex": 147, + "score": "strong" + }, + { + "index": 18, + "title": "Why Issues Matter", + "startSegmentIndex": 181, + "score": "strong" + }, + { + "index": 19, + "title": "2. The Source Control Panel - Complete Walkthrough", + "startSegmentIndex": 232, + "score": "strong" + }, + { + "index": 20, + "title": "3. Branch Management", + "startSegmentIndex": 261, + "score": "strong" + }, + { + "index": 21, + "title": "4. Staging Changes - Files, Lines, and Chunks", + "startSegmentIndex": 326, + "score": "strong" + }, + { + "index": 22, + "title": "6. Push and Pull Operations", + "startSegmentIndex": 390, + "score": "strong" + }, + { + "index": 23, + "title": "What to do if push fails", + "startSegmentIndex": 421, + "score": "strong" + }, + { + "index": 24, + "title": "Syncing Your Fork with the Upstream Repository", + "startSegmentIndex": 433, + "score": "strong" + }, + { + "index": 25, + "title": "7. Discarding Changes", + "startSegmentIndex": 452, + "score": "strong" + }, + { + "index": 26, + "title": "8. Timeline View - File History and Blame", + "startSegmentIndex": 497, + "score": "strong" + }, + { + "index": 27, + "title": "9. Resolving Merge Conflicts in VS Code", + "startSegmentIndex": 547, + "score": "strong" + }, + { + "index": 28, + "title": "10. Stash Management", + "startSegmentIndex": 570, + "score": "strong" + }, + { + "index": 29, + "title": "10b. Emergency Recovery - git reflog", + "startSegmentIndex": 623, + "score": "strong" + }, + { + "index": 30, + "title": "11. Alternative Git Interfaces", + "startSegmentIndex": 642, + "score": "strong" + }, + { + "index": 31, + "title": "Clone, Branch, Commit", + "startSegmentIndex": 660, + "score": "strong" + }, + { + "index": 32, + "title": "Go Local: Final Checkpoint", + "startSegmentIndex": 666, + "score": "strong" + } + ] + }, + { + "slug": "cc-11-day-2-pull-request", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-11-day-2-pull-request-chapters.json", + "chapterCount": 38, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 11: Open a Day 2 PR", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Example PR", + "startSegmentIndex": 21, + "score": "strong" + }, + { + "index": 3, + "title": "What matters", + "startSegmentIndex": 23, + "score": "strong" + }, + { + "index": 4, + "title": "Managing Repositories, Branches, and Changes Accessibly", + "startSegmentIndex": 25, + "score": "strong" + }, + { + "index": 5, + "title": "Why Issues Matter", + "startSegmentIndex": 63, + "score": "strong" + }, + { + "index": 6, + "title": "2. The Source Control Panel - Complete Walkthrough", + "startSegmentIndex": 117, + "score": "strong" + }, + { + "index": 7, + "title": "3. Branch Management", + "startSegmentIndex": 149, + "score": "strong" + }, + { + "index": 8, + "title": "4. Staging Changes - Files, Lines, and Chunks", + "startSegmentIndex": 219, + "score": "strong" + }, + { + "index": 9, + "title": "6. Push and Pull Operations", + "startSegmentIndex": 285, + "score": "strong" + }, + { + "index": 10, + "title": "What to do if push fails", + "startSegmentIndex": 316, + "score": "strong" + }, + { + "index": 11, + "title": "Syncing Your Fork with the Upstream Repository", + "startSegmentIndex": 328, + "score": "strong" + }, + { + "index": 12, + "title": "7. Discarding Changes", + "startSegmentIndex": 350, + "score": "strong" + }, + { + "index": 13, + "title": "8. Timeline View - File History and Blame", + "startSegmentIndex": 395, + "score": "strong" + }, + { + "index": 14, + "title": "9. Resolving Merge Conflicts in VS Code", + "startSegmentIndex": 446, + "score": "strong" + }, + { + "index": 15, + "title": "10. Stash Management", + "startSegmentIndex": 468, + "score": "strong" + }, + { + "index": 16, + "title": "10b. Emergency Recovery - git reflog", + "startSegmentIndex": 521, + "score": "strong" + }, + { + "index": 17, + "title": "11. Alternative Git Interfaces", + "startSegmentIndex": 541, + "score": "strong" + }, + { + "index": 18, + "title": "Clone, Branch, Commit", + "startSegmentIndex": 557, + "score": "strong" + }, + { + "index": 19, + "title": "The GitHub Pull Requests Extension", + "startSegmentIndex": 562, + "score": "strong" + }, + { + "index": 20, + "title": "Managing Pull Requests from VS Code", + "startSegmentIndex": 565, + "score": "strong" + }, + { + "index": 21, + "title": "Why Issues Matter", + "startSegmentIndex": 593, + "score": "strong" + }, + { + "index": 22, + "title": "1. Installing the GitHub Pull Requests Extension", + "startSegmentIndex": 597, + "score": "strong" + }, + { + "index": 23, + "title": "Method 2: Explorer Section", + "startSegmentIndex": 630, + "score": "strong" + }, + { + "index": 24, + "title": "3. Checking Out a Pull Request Branch", + "startSegmentIndex": 648, + "score": "strong" + }, + { + "index": 25, + "title": "4. Reviewing Pull Requests in VS Code", + "startSegmentIndex": 670, + "score": "strong" + }, + { + "index": 26, + "title": "6. Pull Request Description Templates", + "startSegmentIndex": 755, + "score": "strong" + }, + { + "index": 27, + "title": "7. Commenting and Requesting Changes", + "startSegmentIndex": 769, + "score": "strong" + }, + { + "index": 28, + "title": "8. Merging Pull Requests", + "startSegmentIndex": 801, + "score": "strong" + }, + { + "index": 29, + "title": "Review a PR from VS Code", + "startSegmentIndex": 847, + "score": "strong" + }, + { + "index": 30, + "title": "Conducting Pull Request Reviews with a Screen Reader", + "startSegmentIndex": 852, + "score": "strong" + }, + { + "index": 31, + "title": "Why Issues Matter", + "startSegmentIndex": 882, + "score": "strong" + }, + { + "index": 32, + "title": "Two Environments for Code Review", + "startSegmentIndex": 889, + "score": "strong" + }, + { + "index": 33, + "title": "Reviewing in VS Code with the Accessible Diff Viewer", + "startSegmentIndex": 945, + "score": "strong" + }, + { + "index": 34, + "title": "Exercises", + "startSegmentIndex": 1007, + "score": "strong" + }, + { + "index": 35, + "title": "Using GitHub Copilot to Understand Code Changes", + "startSegmentIndex": 1133, + "score": "strong" + }, + { + "index": 36, + "title": "The Reviewer's Craft", + "startSegmentIndex": 1159, + "score": "strong" + }, + { + "index": 37, + "title": "Day 2 Teaser: The Full Accessibility Agents Review Ecosystem", + "startSegmentIndex": 1175, + "score": "strong" + }, + { + "index": 38, + "title": "Open a Day 2 PR: Final Checkpoint", + "startSegmentIndex": 1195, + "score": "strong" + } + ] + }, + { + "slug": "cc-12-code-review", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-12-code-review-chapters.json", + "chapterCount": 47, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 12: Review Like a Pro", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Types of review comments", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 3, + "title": "What matters", + "startSegmentIndex": 35, + "score": "strong" + }, + { + "index": 4, + "title": "The GitHub Pull Requests Extension", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 5, + "title": "Managing Pull Requests from VS Code", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 6, + "title": "Why Issues Matter", + "startSegmentIndex": 71, + "score": "strong" + }, + { + "index": 7, + "title": "1. Installing the GitHub Pull Requests Extension", + "startSegmentIndex": 76, + "score": "strong" + }, + { + "index": 8, + "title": "Method 2: Explorer Section", + "startSegmentIndex": 112, + "score": "strong" + }, + { + "index": 9, + "title": "3. Checking Out a Pull Request Branch", + "startSegmentIndex": 133, + "score": "strong" + }, + { + "index": 10, + "title": "4. Reviewing Pull Requests in VS Code", + "startSegmentIndex": 157, + "score": "strong" + }, + { + "index": 11, + "title": "6. Pull Request Description Templates", + "startSegmentIndex": 242, + "score": "strong" + }, + { + "index": 12, + "title": "7. Commenting and Requesting Changes", + "startSegmentIndex": 255, + "score": "strong" + }, + { + "index": 13, + "title": "8. Merging Pull Requests", + "startSegmentIndex": 288, + "score": "strong" + }, + { + "index": 14, + "title": "Review a PR from VS Code", + "startSegmentIndex": 336, + "score": "strong" + }, + { + "index": 15, + "title": "Conducting Pull Request Reviews with a Screen Reader", + "startSegmentIndex": 341, + "score": "strong" + }, + { + "index": 16, + "title": "Why Issues Matter", + "startSegmentIndex": 372, + "score": "strong" + }, + { + "index": 17, + "title": "Two Environments for Code Review", + "startSegmentIndex": 380, + "score": "strong" + }, + { + "index": 18, + "title": "Reviewing in VS Code with the Accessible Diff Viewer", + "startSegmentIndex": 436, + "score": "strong" + }, + { + "index": 19, + "title": "Exercises", + "startSegmentIndex": 498, + "score": "strong" + }, + { + "index": 20, + "title": "Using GitHub Copilot to Understand Code Changes", + "startSegmentIndex": 624, + "score": "strong" + }, + { + "index": 21, + "title": "The Reviewer's Craft", + "startSegmentIndex": 649, + "score": "strong" + }, + { + "index": 22, + "title": "Day 2 Teaser: The Full Accessibility Agents Review Ecosystem", + "startSegmentIndex": 666, + "score": "strong" + }, + { + "index": 23, + "title": "How to Be an Effective and Respectful Open Source Contributor", + "startSegmentIndex": 685, + "score": "strong" + }, + { + "index": 24, + "title": "Why Issues Matter", + "startSegmentIndex": 709, + "score": "strong" + }, + { + "index": 25, + "title": "GitHub Flow - The Standard Contribution Workflow", + "startSegmentIndex": 712, + "score": "strong" + }, + { + "index": 26, + "title": "Keeping Your Fork Up to Date", + "startSegmentIndex": 738, + "score": "strong" + }, + { + "index": 27, + "title": "When to sync", + "startSegmentIndex": 757, + "score": "strong" + }, + { + "index": 28, + "title": "Writing Good Commit Messages", + "startSegmentIndex": 767, + "score": "strong" + }, + { + "index": 29, + "title": "The Nature of Open Source Communication", + "startSegmentIndex": 787, + "score": "strong" + }, + { + "index": 30, + "title": "The Anatomy of Helpful Feedback", + "startSegmentIndex": 798, + "score": "strong" + }, + { + "index": 31, + "title": "Inclusive Commenting for Accessibility Issues", + "startSegmentIndex": 862, + "score": "strong" + }, + { + "index": 32, + "title": "The \"Good First Issue\" Social Contract", + "startSegmentIndex": 865, + "score": "strong" + }, + { + "index": 33, + "title": "Writing Your First README", + "startSegmentIndex": 885, + "score": "strong" + }, + { + "index": 34, + "title": "Community Health Files", + "startSegmentIndex": 896, + "score": "strong" + }, + { + "index": 35, + "title": "When to Use Different Communication Channels", + "startSegmentIndex": 913, + "score": "strong" + }, + { + "index": 36, + "title": "Rewrite One Comment", + "startSegmentIndex": 916, + "score": "strong" + }, + { + "index": 37, + "title": "Contributing to Open Source", + "startSegmentIndex": 921, + "score": "strong" + }, + { + "index": 38, + "title": "A Guide for First-Time Contributors", + "startSegmentIndex": 924, + "score": "strong" + }, + { + "index": 39, + "title": "1. What Is Open Source?", + "startSegmentIndex": 925, + "score": "strong" + }, + { + "index": 40, + "title": "2. Who Can Contribute?", + "startSegmentIndex": 928, + "score": "strong" + }, + { + "index": 41, + "title": "3. What Makes a Good First Contribution?", + "startSegmentIndex": 930, + "score": "strong" + }, + { + "index": 42, + "title": "4. Finding Something to Work On", + "startSegmentIndex": 935, + "score": "strong" + }, + { + "index": 43, + "title": "5. Reading an Issue Before You Start", + "startSegmentIndex": 940, + "score": "strong" + }, + { + "index": 44, + "title": "7. Getting Help", + "startSegmentIndex": 957, + "score": "strong" + }, + { + "index": 45, + "title": "8. After Your Contribution Is Merged", + "startSegmentIndex": 961, + "score": "strong" + }, + { + "index": 46, + "title": "9. Building a Contribution Habit", + "startSegmentIndex": 963, + "score": "strong" + }, + { + "index": 47, + "title": "Review Like a Pro: Final Checkpoint", + "startSegmentIndex": 968, + "score": "strong" + } + ] + }, + { + "slug": "cc-13-copilot-as-collaborator", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-13-copilot-as-collaborator-chapters.json", + "chapterCount": 21, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 13: AI as Your Copilot", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Example interaction transcript", + "startSegmentIndex": 22, + "score": "strong" + }, + { + "index": 3, + "title": "Before and after", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 4, + "title": "Critical evaluation notes", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 5, + "title": "Alternate approaches", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 6, + "title": "What matters", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 7, + "title": "AI-Powered Code Assistance in VS Code", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 8, + "title": "Why Issues Matter", + "startSegmentIndex": 72, + "score": "strong" + }, + { + "index": 9, + "title": "1. What is GitHub Copilot", + "startSegmentIndex": 78, + "score": "strong" + }, + { + "index": 10, + "title": "3. Inline Suggestions - Ghost Text Completions", + "startSegmentIndex": 104, + "score": "strong" + }, + { + "index": 11, + "title": "4. GitHub Copilot Chat - Conversational Assistance", + "startSegmentIndex": 151, + "score": "strong" + }, + { + "index": 12, + "title": "5. Copilot Edits -- Making Multi-File Changes", + "startSegmentIndex": 187, + "score": "strong" + }, + { + "index": 13, + "title": "6. Agent Mode -- Let Copilot Drive", + "startSegmentIndex": 206, + "score": "strong" + }, + { + "index": 14, + "title": "7. Next Edit Suggestions", + "startSegmentIndex": 219, + "score": "strong" + }, + { + "index": 15, + "title": "8. Copilot on GitHub.com", + "startSegmentIndex": 226, + "score": "strong" + }, + { + "index": 16, + "title": "9. Effective Prompting for Documentation Work", + "startSegmentIndex": 243, + "score": "strong" + }, + { + "index": 17, + "title": "10. Custom Instructions vs Custom Agents", + "startSegmentIndex": 263, + "score": "strong" + }, + { + "index": 18, + "title": "11. Using Accessible View with Copilot Responses", + "startSegmentIndex": 310, + "score": "strong" + }, + { + "index": 19, + "title": "13. Critically Evaluating AI Output", + "startSegmentIndex": 345, + "score": "strong" + }, + { + "index": 20, + "title": "Your First Copilot Conversation", + "startSegmentIndex": 392, + "score": "strong" + }, + { + "index": 21, + "title": "AI as Your Copilot: Final Checkpoint", + "startSegmentIndex": 396, + "score": "strong" + } + ] + }, + { + "slug": "cc-14-design-an-issue-template", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-14-design-an-issue-template-chapters.json", + "chapterCount": 15, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 14: Template Remix", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Example template", + "startSegmentIndex": 21, + "score": "strong" + }, + { + "index": 3, + "title": "Alternate valid templates", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 4, + "title": "What matters", + "startSegmentIndex": 27, + "score": "strong" + }, + { + "index": 5, + "title": "Structuring Contributions for Clarity and Quality", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 6, + "title": "Why Issues Matter", + "startSegmentIndex": 77, + "score": "strong" + }, + { + "index": 7, + "title": "1. What Is an Issue Template?", + "startSegmentIndex": 82, + "score": "strong" + }, + { + "index": 8, + "title": "2. How Templates Work on GitHub", + "startSegmentIndex": 88, + "score": "strong" + }, + { + "index": 9, + "title": "3. Navigating the Template Picker", + "startSegmentIndex": 98, + "score": "strong" + }, + { + "index": 10, + "title": "4. The Accessibility Agents Issue Templates", + "startSegmentIndex": 111, + "score": "strong" + }, + { + "index": 11, + "title": "6. YAML Form-Based Templates", + "startSegmentIndex": 172, + "score": "strong" + }, + { + "index": 12, + "title": "7. Building an Accessibility Bug Report Template", + "startSegmentIndex": 207, + "score": "strong" + }, + { + "index": 13, + "title": "8. Pull Request Templates", + "startSegmentIndex": 220, + "score": "strong" + }, + { + "index": 14, + "title": "10. Day 2 Amplifier: The Template Builder Agent", + "startSegmentIndex": 430, + "score": "strong" + }, + { + "index": 15, + "title": "Template Remix: Final Checkpoint", + "startSegmentIndex": 438, + "score": "strong" + } + ] + }, + { + "slug": "cc-15-discover-accessibility-agents", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-15-discover-accessibility-agents-chapters.json", + "chapterCount": 29, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 15: Meet the Agents", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Example: Running an agent", + "startSegmentIndex": 26, + "score": "strong" + }, + { + "index": 3, + "title": "Example: Reading agent instructions", + "startSegmentIndex": 29, + "score": "strong" + }, + { + "index": 4, + "title": "What matters", + "startSegmentIndex": 33, + "score": "strong" + }, + { + "index": 5, + "title": "55 AI Agents Across 3 Teams and 5 Platforms", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 6, + "title": "Why Issues Matter", + "startSegmentIndex": 85, + "score": "strong" + }, + { + "index": 7, + "title": "Capstone: Share Your Feedback (The Most Important Task!)", + "startSegmentIndex": 93, + "score": "strong" + }, + { + "index": 8, + "title": "1. The Principle: Skill First, Agent Second", + "startSegmentIndex": 97, + "score": "strong" + }, + { + "index": 9, + "title": "3. The Ecosystem: 55 Agents, 3 Teams, 5 Platforms", + "startSegmentIndex": 163, + "score": "strong" + }, + { + "index": 10, + "title": "4. Agents in Detail - Hands-On Reference", + "startSegmentIndex": 189, + "score": "strong" + }, + { + "index": 11, + "title": "5. Slash Commands and Prompts", + "startSegmentIndex": 237, + "score": "strong" + }, + { + "index": 12, + "title": "6. Contributing to the Ecosystem", + "startSegmentIndex": 247, + "score": "strong" + }, + { + "index": 13, + "title": "7. The Bigger Picture: Teams, Orchestration, and Beyond VS Code", + "startSegmentIndex": 325, + "score": "strong" + }, + { + "index": 14, + "title": "8. GitHub Desktop, GitHub CLI, and Copilot CLI", + "startSegmentIndex": 353, + "score": "strong" + }, + { + "index": 15, + "title": "Example session", + "startSegmentIndex": 374, + "score": "strong" + }, + { + "index": 16, + "title": "Complete Reference - Agents, Slash Commands, Instructions,.", + "startSegmentIndex": 394, + "score": "strong" + }, + { + "index": 17, + "title": "1. The Full Agent Ecosystem", + "startSegmentIndex": 395, + "score": "strong" + }, + { + "index": 18, + "title": "2. GitHub Workflow Agents - Quick Reference", + "startSegmentIndex": 400, + "score": "strong" + }, + { + "index": 19, + "title": "3. Slash Commands and Prompts", + "startSegmentIndex": 424, + "score": "strong" + }, + { + "index": 20, + "title": "4. Customization Primitives - Decision Guide", + "startSegmentIndex": 425, + "score": "strong" + }, + { + "index": 21, + "title": "5. Scope and Priority - All Levels", + "startSegmentIndex": 441, + "score": "strong" + }, + { + "index": 22, + "title": "6. Always-On Instructions - All File Types", + "startSegmentIndex": 451, + "score": "strong" + }, + { + "index": 23, + "title": "7. File-Based Instructions (.instructions.md)", + "startSegmentIndex": 466, + "score": "strong" + }, + { + "index": 24, + "title": "[Section Header]", + "startSegmentIndex": 482, + "score": "strong" + }, + { + "index": 25, + "title": "10. Agent Skills (SKILL.md) - Complete Format Reference", + "startSegmentIndex": 508, + "score": "strong" + }, + { + "index": 26, + "title": "11. Hooks (.json) - Lifecycle Automation", + "startSegmentIndex": 514, + "score": "strong" + }, + { + "index": 27, + "title": "12. preferences.md - Accessibility Agents Personal Settings", + "startSegmentIndex": 529, + "score": "strong" + }, + { + "index": 28, + "title": "14. Further Reading", + "startSegmentIndex": 560, + "score": "strong" + }, + { + "index": 29, + "title": "Meet the Agents: Final Checkpoint", + "startSegmentIndex": 565, + "score": "strong" + } + ] + }, + { + "slug": "cc-16-build-your-own-agent", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-16-build-your-own-agent-chapters.json", + "chapterCount": 24, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge 16: Build Your Agent (Capstone)", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Example agent file", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 3, + "title": "Alternate valid agents", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 4, + "title": "What matters", + "startSegmentIndex": 38, + "score": "strong" + }, + { + "index": 5, + "title": "1. The Capstone Challenge", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 6, + "title": "2. Phase 1: Choose Your Agent's Mission", + "startSegmentIndex": 51, + "score": "strong" + }, + { + "index": 7, + "title": "3. Phase 2: Write the Agent File", + "startSegmentIndex": 57, + "score": "strong" + }, + { + "index": 8, + "title": "4. Phase 3: Define Responsibilities and Guardrails", + "startSegmentIndex": 73, + "score": "strong" + }, + { + "index": 9, + "title": "5. Phase 4: Test Your Agent Locally", + "startSegmentIndex": 85, + "score": "strong" + }, + { + "index": 10, + "title": "7. Phase 6: Respond to Review", + "startSegmentIndex": 129, + "score": "strong" + }, + { + "index": 11, + "title": "8. Capstone Rubric", + "startSegmentIndex": 141, + "score": "strong" + }, + { + "index": 12, + "title": "9. Example Agents for Inspiration", + "startSegmentIndex": 149, + "score": "strong" + }, + { + "index": 13, + "title": "55 AI Agents Across 3 Teams and 5 Platforms", + "startSegmentIndex": 161, + "score": "strong" + }, + { + "index": 14, + "title": "Why Issues Matter", + "startSegmentIndex": 208, + "score": "strong" + }, + { + "index": 15, + "title": "Capstone: Share Your Feedback (The Most Important Task!)", + "startSegmentIndex": 213, + "score": "strong" + }, + { + "index": 16, + "title": "1. The Principle: Skill First, Agent Second", + "startSegmentIndex": 218, + "score": "strong" + }, + { + "index": 17, + "title": "3. The Ecosystem: 55 Agents, 3 Teams, 5 Platforms", + "startSegmentIndex": 278, + "score": "strong" + }, + { + "index": 18, + "title": "4. Agents in Detail - Hands-On Reference", + "startSegmentIndex": 303, + "score": "strong" + }, + { + "index": 19, + "title": "5. Slash Commands and Prompts", + "startSegmentIndex": 352, + "score": "strong" + }, + { + "index": 20, + "title": "6. Contributing to the Ecosystem", + "startSegmentIndex": 361, + "score": "strong" + }, + { + "index": 21, + "title": "7. The Bigger Picture: Teams, Orchestration, and Beyond VS Code", + "startSegmentIndex": 439, + "score": "strong" + }, + { + "index": 22, + "title": "8. GitHub Desktop, GitHub CLI, and Copilot CLI", + "startSegmentIndex": 467, + "score": "strong" + }, + { + "index": 23, + "title": "Example session", + "startSegmentIndex": 489, + "score": "strong" + }, + { + "index": 24, + "title": "Build Your Agent (Capstone): Final Checkpoint", + "startSegmentIndex": 509, + "score": "strong" + } + ] + }, + { + "slug": "cc-bonus-a-improve-agent", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-bonus-a-improve-agent-chapters.json", + "chapterCount": 24, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge bonus-a: Improve an Agent", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Bonus A: Improve an Existing Agent", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Example improvement", + "startSegmentIndex": 21, + "score": "strong" + }, + { + "index": 4, + "title": "What matters", + "startSegmentIndex": 22, + "score": "strong" + }, + { + "index": 5, + "title": "55 AI Agents Across 3 Teams and 5 Platforms", + "startSegmentIndex": 24, + "score": "strong" + }, + { + "index": 6, + "title": "Why Issues Matter", + "startSegmentIndex": 74, + "score": "strong" + }, + { + "index": 7, + "title": "Capstone: Share Your Feedback (The Most Important Task!)", + "startSegmentIndex": 81, + "score": "strong" + }, + { + "index": 8, + "title": "1. The Principle: Skill First, Agent Second", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 9, + "title": "3. The Ecosystem: 55 Agents, 3 Teams, 5 Platforms", + "startSegmentIndex": 156, + "score": "strong" + }, + { + "index": 10, + "title": "4. Agents in Detail - Hands-On Reference", + "startSegmentIndex": 183, + "score": "strong" + }, + { + "index": 11, + "title": "5. Slash Commands and Prompts", + "startSegmentIndex": 229, + "score": "strong" + }, + { + "index": 12, + "title": "6. Contributing to the Ecosystem", + "startSegmentIndex": 240, + "score": "strong" + }, + { + "index": 13, + "title": "7. The Bigger Picture: Teams, Orchestration, and Beyond VS Code", + "startSegmentIndex": 313, + "score": "strong" + }, + { + "index": 14, + "title": "8. GitHub Desktop, GitHub CLI, and Copilot CLI", + "startSegmentIndex": 341, + "score": "strong" + }, + { + "index": 15, + "title": "Example session", + "startSegmentIndex": 363, + "score": "strong" + }, + { + "index": 16, + "title": "1. The Capstone Challenge", + "startSegmentIndex": 384, + "score": "strong" + }, + { + "index": 17, + "title": "2. Phase 1: Choose Your Agent's Mission", + "startSegmentIndex": 394, + "score": "strong" + }, + { + "index": 18, + "title": "3. Phase 2: Write the Agent File", + "startSegmentIndex": 400, + "score": "strong" + }, + { + "index": 19, + "title": "4. Phase 3: Define Responsibilities and Guardrails", + "startSegmentIndex": 414, + "score": "strong" + }, + { + "index": 20, + "title": "5. Phase 4: Test Your Agent Locally", + "startSegmentIndex": 425, + "score": "strong" + }, + { + "index": 21, + "title": "7. Phase 6: Respond to Review", + "startSegmentIndex": 464, + "score": "strong" + }, + { + "index": 22, + "title": "8. Capstone Rubric", + "startSegmentIndex": 474, + "score": "strong" + }, + { + "index": 23, + "title": "9. Example Agents for Inspiration", + "startSegmentIndex": 482, + "score": "strong" + }, + { + "index": 24, + "title": "Improve an Agent: Final Checkpoint", + "startSegmentIndex": 495, + "score": "strong" + } + ] + }, + { + "slug": "cc-bonus-b-document-your-journey", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-bonus-b-document-your-journey-chapters.json", + "chapterCount": 61, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge bonus-b: Document Your Journey", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Bonus B: Document Your Journey", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "What matters", + "startSegmentIndex": 12, + "score": "strong" + }, + { + "index": 4, + "title": "How to Be an Effective and Respectful Open Source Contributor", + "startSegmentIndex": 17, + "score": "strong" + }, + { + "index": 5, + "title": "Why Issues Matter", + "startSegmentIndex": 43, + "score": "strong" + }, + { + "index": 6, + "title": "GitHub Flow - The Standard Contribution Workflow", + "startSegmentIndex": 49, + "score": "strong" + }, + { + "index": 7, + "title": "Keeping Your Fork Up to Date", + "startSegmentIndex": 77, + "score": "strong" + }, + { + "index": 8, + "title": "When to sync", + "startSegmentIndex": 99, + "score": "strong" + }, + { + "index": 9, + "title": "Writing Good Commit Messages", + "startSegmentIndex": 111, + "score": "strong" + }, + { + "index": 10, + "title": "The Nature of Open Source Communication", + "startSegmentIndex": 138, + "score": "strong" + }, + { + "index": 11, + "title": "The Anatomy of Helpful Feedback", + "startSegmentIndex": 148, + "score": "strong" + }, + { + "index": 12, + "title": "Inclusive Commenting for Accessibility Issues", + "startSegmentIndex": 212, + "score": "strong" + }, + { + "index": 13, + "title": "The \"Good First Issue\" Social Contract", + "startSegmentIndex": 214, + "score": "strong" + }, + { + "index": 14, + "title": "Writing Your First README", + "startSegmentIndex": 234, + "score": "strong" + }, + { + "index": 15, + "title": "Community Health Files", + "startSegmentIndex": 245, + "score": "strong" + }, + { + "index": 16, + "title": "When to Use Different Communication Channels", + "startSegmentIndex": 262, + "score": "strong" + }, + { + "index": 17, + "title": "Rewrite One Comment", + "startSegmentIndex": 265, + "score": "strong" + }, + { + "index": 18, + "title": "Contributing to Open Source", + "startSegmentIndex": 271, + "score": "strong" + }, + { + "index": 19, + "title": "A Guide for First-Time Contributors", + "startSegmentIndex": 272, + "score": "strong" + }, + { + "index": 20, + "title": "1. What Is Open Source?", + "startSegmentIndex": 274, + "score": "strong" + }, + { + "index": 21, + "title": "2. Who Can Contribute?", + "startSegmentIndex": 277, + "score": "strong" + }, + { + "index": 22, + "title": "3. What Makes a Good First Contribution?", + "startSegmentIndex": 279, + "score": "strong" + }, + { + "index": 23, + "title": "4. Finding Something to Work On", + "startSegmentIndex": 285, + "score": "strong" + }, + { + "index": 24, + "title": "5. Reading an Issue Before You Start", + "startSegmentIndex": 289, + "score": "strong" + }, + { + "index": 25, + "title": "7. Getting Help", + "startSegmentIndex": 307, + "score": "strong" + }, + { + "index": 26, + "title": "8. After Your Contribution Is Merged", + "startSegmentIndex": 309, + "score": "strong" + }, + { + "index": 27, + "title": "9. Building a Contribution Habit", + "startSegmentIndex": 312, + "score": "strong" + }, + { + "index": 28, + "title": "From First Paragraph to Polished Repository - Everything You.", + "startSegmentIndex": 317, + "score": "strong" + }, + { + "index": 29, + "title": "1. What Is Markdown?", + "startSegmentIndex": 337, + "score": "strong" + }, + { + "index": 30, + "title": "2. Where You Will Use Markdown in This Workshop", + "startSegmentIndex": 345, + "score": "strong" + }, + { + "index": 31, + "title": "3. How to Practice as You Read", + "startSegmentIndex": 352, + "score": "strong" + }, + { + "index": 32, + "title": "4. Paragraphs and Line Breaks", + "startSegmentIndex": 369, + "score": "strong" + }, + { + "index": 33, + "title": "5. Headings", + "startSegmentIndex": 376, + "score": "strong" + }, + { + "index": 34, + "title": "6. Emphasis - Bold, Italic, and Bold Italic", + "startSegmentIndex": 384, + "score": "strong" + }, + { + "index": 35, + "title": "7. Strikethrough", + "startSegmentIndex": 396, + "score": "strong" + }, + { + "index": 36, + "title": "8. Lists - Ordered and Unordered", + "startSegmentIndex": 399, + "score": "strong" + }, + { + "index": 37, + "title": "9. Nested Lists and Mixed Lists", + "startSegmentIndex": 410, + "score": "strong" + }, + { + "index": 38, + "title": "10. Links", + "startSegmentIndex": 424, + "score": "strong" + }, + { + "index": 39, + "title": "11. Images", + "startSegmentIndex": 441, + "score": "strong" + }, + { + "index": 40, + "title": "12. Blockquotes", + "startSegmentIndex": 453, + "score": "strong" + }, + { + "index": 41, + "title": "13. Inline Code and Code Blocks", + "startSegmentIndex": 464, + "score": "strong" + }, + { + "index": 42, + "title": "14. Horizontal Rules", + "startSegmentIndex": 479, + "score": "strong" + }, + { + "index": 43, + "title": "15. Escaping Special Characters", + "startSegmentIndex": 481, + "score": "strong" + }, + { + "index": 44, + "title": "16. Tables", + "startSegmentIndex": 486, + "score": "strong" + }, + { + "index": 45, + "title": "17. What Is GitHub Flavored Markdown?", + "startSegmentIndex": 511, + "score": "strong" + }, + { + "index": 46, + "title": "18. Alert and Callout Blocks", + "startSegmentIndex": 515, + "score": "strong" + }, + { + "index": 47, + "title": "19. Collapsible Sections with Details and Summary", + "startSegmentIndex": 524, + "score": "strong" + }, + { + "index": 48, + "title": "20. Task List Checkboxes", + "startSegmentIndex": 540, + "score": "strong" + }, + { + "index": 49, + "title": "21. Syntax Highlighting in Fenced Code Blocks", + "startSegmentIndex": 557, + "score": "strong" + }, + { + "index": 50, + "title": "22. Mermaid Diagrams", + "startSegmentIndex": 565, + "score": "strong" + }, + { + "index": 51, + "title": "23. Math Expressions with LaTeX", + "startSegmentIndex": 575, + "score": "strong" + }, + { + "index": 52, + "title": "24. Footnotes", + "startSegmentIndex": 586, + "score": "strong" + }, + { + "index": 53, + "title": "25. Linked Heading Anchors and Tables of Contents", + "startSegmentIndex": 598, + "score": "strong" + }, + { + "index": 54, + "title": "26. Autolinked References - Issues, PRs, Commits, and Users", + "startSegmentIndex": 610, + "score": "strong" + }, + { + "index": 55, + "title": "27. HTML in Markdown", + "startSegmentIndex": 621, + "score": "strong" + }, + { + "index": 56, + "title": "28. Screen Reader Behavior Summary", + "startSegmentIndex": 632, + "score": "strong" + }, + { + "index": 57, + "title": "29. Accessible Markdown Authoring Checklist", + "startSegmentIndex": 634, + "score": "strong" + }, + { + "index": 58, + "title": "30. Common Mistakes and How to Fix Them", + "startSegmentIndex": 658, + "score": "strong" + }, + { + "index": 59, + "title": "31. Your First Real Markdown Document - Guided Exercise", + "startSegmentIndex": 679, + "score": "strong" + }, + { + "index": 60, + "title": "32. Quick-Reference Card", + "startSegmentIndex": 705, + "score": "strong" + }, + { + "index": 61, + "title": "Document Your Journey: Final Checkpoint", + "startSegmentIndex": 714, + "score": "strong" + } + ] + }, + { + "slug": "cc-bonus-c-group-challenge", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-bonus-c-group-challenge-chapters.json", + "chapterCount": 47, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge bonus-c: Group Challenge", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Bonus C: Create a Group Challenge", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "What matters", + "startSegmentIndex": 31, + "score": "strong" + }, + { + "index": 4, + "title": "How to Be an Effective and Respectful Open Source Contributor", + "startSegmentIndex": 34, + "score": "strong" + }, + { + "index": 5, + "title": "Why Issues Matter", + "startSegmentIndex": 61, + "score": "strong" + }, + { + "index": 6, + "title": "GitHub Flow - The Standard Contribution Workflow", + "startSegmentIndex": 65, + "score": "strong" + }, + { + "index": 7, + "title": "Keeping Your Fork Up to Date", + "startSegmentIndex": 95, + "score": "strong" + }, + { + "index": 8, + "title": "When to sync", + "startSegmentIndex": 118, + "score": "strong" + }, + { + "index": 9, + "title": "Writing Good Commit Messages", + "startSegmentIndex": 128, + "score": "strong" + }, + { + "index": 10, + "title": "The Nature of Open Source Communication", + "startSegmentIndex": 150, + "score": "strong" + }, + { + "index": 11, + "title": "The Anatomy of Helpful Feedback", + "startSegmentIndex": 161, + "score": "strong" + }, + { + "index": 12, + "title": "Inclusive Commenting for Accessibility Issues", + "startSegmentIndex": 225, + "score": "strong" + }, + { + "index": 13, + "title": "The \"Good First Issue\" Social Contract", + "startSegmentIndex": 228, + "score": "strong" + }, + { + "index": 14, + "title": "Writing Your First README", + "startSegmentIndex": 248, + "score": "strong" + }, + { + "index": 15, + "title": "Community Health Files", + "startSegmentIndex": 259, + "score": "strong" + }, + { + "index": 16, + "title": "When to Use Different Communication Channels", + "startSegmentIndex": 276, + "score": "strong" + }, + { + "index": 17, + "title": "Rewrite One Comment", + "startSegmentIndex": 279, + "score": "strong" + }, + { + "index": 18, + "title": "Contributing to Open Source", + "startSegmentIndex": 284, + "score": "strong" + }, + { + "index": 19, + "title": "A Guide for First-Time Contributors", + "startSegmentIndex": 287, + "score": "strong" + }, + { + "index": 20, + "title": "1. What Is Open Source?", + "startSegmentIndex": 288, + "score": "strong" + }, + { + "index": 21, + "title": "2. Who Can Contribute?", + "startSegmentIndex": 291, + "score": "strong" + }, + { + "index": 22, + "title": "3. What Makes a Good First Contribution?", + "startSegmentIndex": 293, + "score": "strong" + }, + { + "index": 23, + "title": "4. Finding Something to Work On", + "startSegmentIndex": 298, + "score": "strong" + }, + { + "index": 24, + "title": "5. Reading an Issue Before You Start", + "startSegmentIndex": 303, + "score": "strong" + }, + { + "index": 25, + "title": "7. Getting Help", + "startSegmentIndex": 320, + "score": "strong" + }, + { + "index": 26, + "title": "8. After Your Contribution Is Merged", + "startSegmentIndex": 324, + "score": "strong" + }, + { + "index": 27, + "title": "9. Building a Contribution Habit", + "startSegmentIndex": 326, + "score": "strong" + }, + { + "index": 28, + "title": "The GitHub Pull Requests Extension", + "startSegmentIndex": 331, + "score": "strong" + }, + { + "index": 29, + "title": "Managing Pull Requests from VS Code", + "startSegmentIndex": 333, + "score": "strong" + }, + { + "index": 30, + "title": "Why Issues Matter", + "startSegmentIndex": 362, + "score": "strong" + }, + { + "index": 31, + "title": "1. Installing the GitHub Pull Requests Extension", + "startSegmentIndex": 365, + "score": "strong" + }, + { + "index": 32, + "title": "Method 2: Explorer Section", + "startSegmentIndex": 398, + "score": "strong" + }, + { + "index": 33, + "title": "3. Checking Out a Pull Request Branch", + "startSegmentIndex": 416, + "score": "strong" + }, + { + "index": 34, + "title": "4. Reviewing Pull Requests in VS Code", + "startSegmentIndex": 439, + "score": "strong" + }, + { + "index": 35, + "title": "6. Pull Request Description Templates", + "startSegmentIndex": 524, + "score": "strong" + }, + { + "index": 36, + "title": "7. Commenting and Requesting Changes", + "startSegmentIndex": 537, + "score": "strong" + }, + { + "index": 37, + "title": "8. Merging Pull Requests", + "startSegmentIndex": 569, + "score": "strong" + }, + { + "index": 38, + "title": "Review a PR from VS Code", + "startSegmentIndex": 617, + "score": "strong" + }, + { + "index": 39, + "title": "Conducting Pull Request Reviews with a Screen Reader", + "startSegmentIndex": 623, + "score": "strong" + }, + { + "index": 40, + "title": "Why Issues Matter", + "startSegmentIndex": 652, + "score": "strong" + }, + { + "index": 41, + "title": "Two Environments for Code Review", + "startSegmentIndex": 660, + "score": "strong" + }, + { + "index": 42, + "title": "Reviewing in VS Code with the Accessible Diff Viewer", + "startSegmentIndex": 716, + "score": "strong" + }, + { + "index": 43, + "title": "Exercises", + "startSegmentIndex": 778, + "score": "strong" + }, + { + "index": 44, + "title": "Using GitHub Copilot to Understand Code Changes", + "startSegmentIndex": 905, + "score": "strong" + }, + { + "index": 45, + "title": "The Reviewer's Craft", + "startSegmentIndex": 930, + "score": "strong" + }, + { + "index": 46, + "title": "Day 2 Teaser: The Full Accessibility Agents Review Ecosystem", + "startSegmentIndex": 946, + "score": "strong" + }, + { + "index": 47, + "title": "Group Challenge: Final Checkpoint", + "startSegmentIndex": 966, + "score": "strong" + } + ] + }, + { + "slug": "cc-bonus-d-notifications", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-bonus-d-notifications-chapters.json", + "chapterCount": 18, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge bonus-d: Notifications", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Bonus D: Notification Mastery", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "Before: Default settings", + "startSegmentIndex": 17, + "score": "strong" + }, + { + "index": 4, + "title": "Key decisions explained", + "startSegmentIndex": 28, + "score": "strong" + }, + { + "index": 5, + "title": "What matters", + "startSegmentIndex": 32, + "score": "strong" + }, + { + "index": 6, + "title": "Managing Your GitHub Notification Inbox", + "startSegmentIndex": 35, + "score": "strong" + }, + { + "index": 7, + "title": "Why Issues Matter", + "startSegmentIndex": 61, + "score": "strong" + }, + { + "index": 8, + "title": "What Generates a Notification?", + "startSegmentIndex": 69, + "score": "strong" + }, + { + "index": 9, + "title": "Notification Subscription Levels", + "startSegmentIndex": 71, + "score": "strong" + }, + { + "index": 10, + "title": "Inbox Actions - Keyboard Shortcuts", + "startSegmentIndex": 94, + "score": "strong" + }, + { + "index": 11, + "title": "Filtering the Inbox", + "startSegmentIndex": 95, + "score": "strong" + }, + { + "index": 12, + "title": "Notification Settings - Per Your Account", + "startSegmentIndex": 119, + "score": "strong" + }, + { + "index": 13, + "title": "Starring vs. Watching - What Is the Difference?", + "startSegmentIndex": 124, + "score": "strong" + }, + { + "index": 14, + "title": "The GitHub Mobile App - A Reference Note", + "startSegmentIndex": 144, + "score": "strong" + }, + { + "index": 15, + "title": "Tame Your Inbox", + "startSegmentIndex": 147, + "score": "strong" + }, + { + "index": 16, + "title": "What You Accomplished Today", + "startSegmentIndex": 150, + "score": "strong" + }, + { + "index": 17, + "title": "What Day 2 Adds", + "startSegmentIndex": 162, + "score": "strong" + }, + { + "index": 18, + "title": "Notifications: Final Checkpoint", + "startSegmentIndex": 170, + "score": "strong" + } + ] + }, + { + "slug": "cc-bonus-e-git-history", + "filePath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\challenges\\cc-bonus-e-git-history-chapters.json", + "chapterCount": 27, + "weakCount": 0, + "genericCount": 0, + "findings": [ + { + "index": 1, + "title": "Challenge bonus-e: Git History", + "startSegmentIndex": 0, + "score": "strong" + }, + { + "index": 2, + "title": "Bonus E: Explore Git History Visually", + "startSegmentIndex": 7, + "score": "strong" + }, + { + "index": 3, + "title": "In VS Code", + "startSegmentIndex": 36, + "score": "strong" + }, + { + "index": 4, + "title": "What matters", + "startSegmentIndex": 39, + "score": "strong" + }, + { + "index": 5, + "title": "1. Why a Mental Model Matters", + "startSegmentIndex": 42, + "score": "strong" + }, + { + "index": 6, + "title": "2. The Three Areas: Working Directory, Staging Area, Repository", + "startSegmentIndex": 43, + "score": "strong" + }, + { + "index": 7, + "title": "3. What Is a Commit?", + "startSegmentIndex": 61, + "score": "strong" + }, + { + "index": 8, + "title": "4. What Is a Branch?", + "startSegmentIndex": 72, + "score": "strong" + }, + { + "index": 9, + "title": "5. Local vs Remote", + "startSegmentIndex": 86, + "score": "strong" + }, + { + "index": 10, + "title": "6. Push, Pull, and Fetch", + "startSegmentIndex": 97, + "score": "strong" + }, + { + "index": 11, + "title": "7. Why Merge Conflicts Happen", + "startSegmentIndex": 112, + "score": "strong" + }, + { + "index": 12, + "title": "8. The Git Timeline", + "startSegmentIndex": 130, + "score": "strong" + }, + { + "index": 13, + "title": "9. Putting It All Together", + "startSegmentIndex": 137, + "score": "strong" + }, + { + "index": 14, + "title": "10. If You Get Stuck", + "startSegmentIndex": 142, + "score": "strong" + }, + { + "index": 15, + "title": "Going Deeper with Git", + "startSegmentIndex": 144, + "score": "strong" + }, + { + "index": 16, + "title": "1. Cherry-Pick -- Grabbing a Specific Commit", + "startSegmentIndex": 149, + "score": "strong" + }, + { + "index": 17, + "title": "2. Interactive Rebase -- Cleaning Up Your History", + "startSegmentIndex": 174, + "score": "strong" + }, + { + "index": 18, + "title": "3. git reset -- Undoing at Different Depths", + "startSegmentIndex": 194, + "score": "strong" + }, + { + "index": 19, + "title": "4. git revert -- The Safe Undo for Shared Branches", + "startSegmentIndex": 213, + "score": "strong" + }, + { + "index": 20, + "title": "5. Tags -- Marking Important Moments", + "startSegmentIndex": 225, + "score": "strong" + }, + { + "index": 21, + "title": "6. Detached HEAD -- What It Is and How to Get Out", + "startSegmentIndex": 244, + "score": "strong" + }, + { + "index": 22, + "title": "7. Force Pushing Safely", + "startSegmentIndex": 255, + "score": "strong" + }, + { + "index": 23, + "title": "8. git bisect -- Finding the Commit That Broke Things", + "startSegmentIndex": 273, + "score": "strong" + }, + { + "index": 24, + "title": "9. git clean -- Clearing Out Untracked Files", + "startSegmentIndex": 286, + "score": "strong" + }, + { + "index": 25, + "title": "10. Branch Protection -- Why Your Push or Merge May Be Blocked", + "startSegmentIndex": 297, + "score": "strong" + }, + { + "index": 26, + "title": "11. Using GitHub Copilot for Git Operations", + "startSegmentIndex": 317, + "score": "strong" + }, + { + "index": 27, + "title": "Git History: Final Checkpoint", + "startSegmentIndex": 340, + "score": "strong" + } + ] + } + ] +} diff --git a/podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.report.json b/podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.report.json new file mode 100644 index 0000000..882f650 --- /dev/null +++ b/podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.report.json @@ -0,0 +1,1069 @@ +{ + "generatedAt": "2026-05-13T01:28:33.836Z", + "sourcePath": "S:\\code\\git-going-with-github\\docs\\05-working-with-issues.md", + "transcriptPath": "S:\\code\\git-going-with-github\\podcasts\\logs\\agentic-pilots\\ep05-working-with-issues-gpt54.txt", + "transcriptWords": 3358, + "transcriptCharacters": 19983, + "headingsAnalyzed": 93, + "coverageSummary": { + "covered": 36, + "partial": 45, + "missing": 12, + "total": 93 + }, + "invalidMarkers": [], + "segmentSummary": { + "ALEX": { + "segments": 51, + "words": 2643 + }, + "JAMIE": { + "segments": 41, + "words": 609 + }, + "PAUSE": { + "segments": 14, + "words": 0 + } + }, + "repeatedStarts": [], + "headingCoverage": [ + { + "level": 2, + "title": "Filing, Managing, and Participating in GitHub Issues", + "status": "missing", + "ratio": 0.4, + "keywords": [ + "filing", + "managing", + "participating", + "github", + "issues" + ] + }, + { + "level": 2, + "title": "Workshop Recommendation (Chapter 5 / Challenges 2-3)", + "status": "partial", + "ratio": 0.6, + "keywords": [ + "workshop", + "recommendation", + "chapter", + "challenges", + "2-3" + ] + }, + { + "level": 3, + "title": "Chapter 5 Challenge Set", + "status": "covered", + "ratio": 1, + "keywords": [ + "chapter", + "challenge", + "set" + ] + }, + { + "level": 3, + "title": "Challenge 2 Step-by-Step: Create Your First Issue", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "challenge", + "step-by-step", + "create", + "first", + "issue" + ] + }, + { + "level": 3, + "title": "Challenge 3 Step-by-Step: Comment and @Mention", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "challenge", + "step-by-step", + "comment", + "@mention" + ] + }, + { + "level": 3, + "title": "Optional Extension Step-by-Step: Add a Sub-Issue", + "status": "partial", + "ratio": 0.6, + "keywords": [ + "optional", + "extension", + "step-by-step", + "add", + "sub-issue" + ] + }, + { + "level": 3, + "title": "Completing Chapter 5: Submit Your Evidence", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "completing", + "chapter", + "submit", + "evidence" + ] + }, + { + "level": 3, + "title": "Expected Outcomes", + "status": "covered", + "ratio": 1, + "keywords": [ + "expected", + "outcomes" + ] + }, + { + "level": 3, + "title": "If You Get Stuck", + "status": "covered", + "ratio": 1, + "keywords": [ + "you", + "get", + "stuck" + ] + }, + { + "level": 3, + "title": "Learning Moment", + "status": "covered", + "ratio": 1, + "keywords": [ + "learning", + "moment" + ] + }, + { + "level": 3, + "title": "Learning Pattern Used in This Chapter", + "status": "covered", + "ratio": 1, + "keywords": [ + "learning", + "pattern", + "used", + "chapter" + ] + }, + { + "level": 3, + "title": "About Learning Cards in This Chapter", + "status": "covered", + "ratio": 1, + "keywords": [ + "about", + "learning", + "cards", + "chapter" + ] + }, + { + "level": 2, + "title": "Local Git Alternative: Working from Your Clone", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "local", + "git", + "alternative", + "working", + "clone" + ] + }, + { + "level": 2, + "title": "What Is a GitHub Issue?", + "status": "covered", + "ratio": 1, + "keywords": [ + "github", + "issue" + ] + }, + { + "level": 2, + "title": "Navigating to the Issues List", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "navigating", + "issues", + "list" + ] + }, + { + "level": 3, + "title": "From a repository page", + "status": "covered", + "ratio": 1, + "keywords": [ + "repository", + "page" + ] + }, + { + "level": 3, + "title": "Direct URL", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "direct", + "url" + ] + }, + { + "level": 3, + "title": "Learning Cards: Navigating to the Issues List", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "learning", + "cards", + "navigating", + "issues", + "list" + ] + }, + { + "level": 2, + "title": "The Issues List Page", + "status": "covered", + "ratio": 1, + "keywords": [ + "issues", + "list", + "page" + ] + }, + { + "level": 3, + "title": "Page structure", + "status": "covered", + "ratio": 1, + "keywords": [ + "page", + "structure" + ] + }, + { + "level": 3, + "title": "How to read the issue list", + "status": "covered", + "ratio": 1, + "keywords": [ + "read", + "issue", + "list" + ] + }, + { + "level": 3, + "title": "What is announced per issue", + "status": "covered", + "ratio": 1, + "keywords": [ + "announced", + "per", + "issue" + ] + }, + { + "level": 3, + "title": "Learning Cards: The Issues List Page", + "status": "covered", + "ratio": 1, + "keywords": [ + "learning", + "cards", + "issues", + "list", + "page" + ] + }, + { + "level": 2, + "title": "Filtering and Searching Issues", + "status": "covered", + "ratio": 1, + "keywords": [ + "filtering", + "searching", + "issues" + ] + }, + { + "level": 3, + "title": "Using the search/filter bar", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "search", + "filter", + "bar" + ] + }, + { + "level": 4, + "title": "Useful filter queries", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "useful", + "filter", + "queries" + ] + }, + { + "level": 3, + "title": "Using the filter buttons", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "filter", + "buttons" + ] + }, + { + "level": 3, + "title": "Open vs Closed filter", + "status": "covered", + "ratio": 1, + "keywords": [ + "open", + "closed", + "filter" + ] + }, + { + "level": 3, + "title": "Learning Cards: Filtering and Searching Issues", + "status": "covered", + "ratio": 1, + "keywords": [ + "learning", + "cards", + "filtering", + "searching", + "issues" + ] + }, + { + "level": 2, + "title": "Reading an Issue", + "status": "covered", + "ratio": 1, + "keywords": [ + "reading", + "issue" + ] + }, + { + "level": 3, + "title": "Landing on an issue page", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "landing", + "issue", + "page" + ] + }, + { + "level": 3, + "title": "Quick navigation", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "quick", + "navigation" + ] + }, + { + "level": 3, + "title": "Reading the issue description", + "status": "covered", + "ratio": 1, + "keywords": [ + "reading", + "issue", + "description" + ] + }, + { + "level": 3, + "title": "Reading comments and activity", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "reading", + "comments", + "activity" + ] + }, + { + "level": 3, + "title": "Learning Cards: Reading an Issue", + "status": "covered", + "ratio": 1, + "keywords": [ + "learning", + "cards", + "reading", + "issue" + ] + }, + { + "level": 2, + "title": "Leaving a Comment", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "leaving", + "comment" + ] + }, + { + "level": 3, + "title": "Step-by-step", + "status": "missing", + "ratio": 0, + "keywords": [ + "step-by-step" + ] + }, + { + "level": 3, + "title": "Markdown formatting while typing", + "status": "missing", + "ratio": 0, + "keywords": [ + "markdown", + "formatting", + "typing" + ] + }, + { + "level": 3, + "title": "GitHub shortcuts for the Issues pages", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "github", + "shortcuts", + "issues", + "pages" + ] + }, + { + "level": 4, + "title": "On the Issues list page", + "status": "covered", + "ratio": 1, + "keywords": [ + "issues", + "list", + "page" + ] + }, + { + "level": 4, + "title": "On an open issue", + "status": "covered", + "ratio": 1, + "keywords": [ + "open", + "issue" + ] + }, + { + "level": 3, + "title": "Learning Cards: Leaving a Comment", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "learning", + "cards", + "leaving", + "comment" + ] + }, + { + "level": 2, + "title": "Filing a New Issue", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "filing", + "new", + "issue" + ] + }, + { + "level": 3, + "title": "Navigating to New Issue", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "navigating", + "new", + "issue" + ] + }, + { + "level": 3, + "title": "Filling Out the Issue Form", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "filling", + "out", + "issue", + "form" + ] + }, + { + "level": 4, + "title": "Title field", + "status": "covered", + "ratio": 1, + "keywords": [ + "title", + "field" + ] + }, + { + "level": 4, + "title": "Description / Body field", + "status": "covered", + "ratio": 1, + "keywords": [ + "description", + "body", + "field" + ] + }, + { + "level": 2, + "title": "What happened", + "status": "covered", + "ratio": 1, + "keywords": [ + "happened" + ] + }, + { + "level": 2, + "title": "What I expected", + "status": "covered", + "ratio": 1, + "keywords": [ + "expected" + ] + }, + { + "level": 2, + "title": "How to reproduce", + "status": "missing", + "ratio": 0, + "keywords": [ + "reproduce" + ] + }, + { + "level": 2, + "title": "Environment", + "status": "missing", + "ratio": 0, + "keywords": [ + "environment" + ] + }, + { + "level": 2, + "title": "Additional context", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "additional", + "context" + ] + }, + { + "level": 3, + "title": "Assigning labels from the sidebar", + "status": "missing", + "ratio": 0.3333333333333333, + "keywords": [ + "assigning", + "labels", + "sidebar" + ] + }, + { + "level": 3, + "title": "Submitting the issue", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "submitting", + "issue" + ] + }, + { + "level": 3, + "title": "Learning Cards: Filing a New Issue", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "learning", + "cards", + "filing", + "new", + "issue" + ] + }, + { + "level": 3, + "title": "Tool Cards: File a New Issue", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "tool", + "cards", + "file", + "new", + "issue" + ] + }, + { + "level": 2, + "title": "Cross-Referencing Issues", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "cross-referencing", + "issues" + ] + }, + { + "level": 3, + "title": "Closing keywords in PR descriptions or issue comments", + "status": "missing", + "ratio": 0.4, + "keywords": [ + "closing", + "keywords", + "descriptions", + "issue", + "comments" + ] + }, + { + "level": 3, + "title": "Mentioning another issue in a comment", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "mentioning", + "another", + "issue", + "comment" + ] + }, + { + "level": 3, + "title": "Cross-repo references", + "status": "missing", + "ratio": 0, + "keywords": [ + "cross-repo", + "references" + ] + }, + { + "level": 3, + "title": "Learning Cards: Cross-Referencing Issues", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "learning", + "cards", + "cross-referencing", + "issues" + ] + }, + { + "level": 2, + "title": "Sub-Issues - Parent and Child Relationships", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "sub-issues", + "parent", + "child", + "relationships" + ] + }, + { + "level": 3, + "title": "When to Use Sub-Issues", + "status": "covered", + "ratio": 1, + "keywords": [ + "sub-issues" + ] + }, + { + "level": 3, + "title": "Creating a Sub-Issue", + "status": "covered", + "ratio": 1, + "keywords": [ + "creating", + "sub-issue" + ] + }, + { + "level": 3, + "title": "Reading Sub-Issues on a Parent Issue", + "status": "covered", + "ratio": 1, + "keywords": [ + "reading", + "sub-issues", + "parent", + "issue" + ] + }, + { + "level": 3, + "title": "Viewing a Child Issue's Parent", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "viewing", + "child", + "issue", + "parent" + ] + }, + { + "level": 3, + "title": "Sub-Issues vs. Task Lists", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "sub-issues", + "task", + "lists" + ] + }, + { + "level": 3, + "title": "Learning Cards: Sub-Issues", + "status": "covered", + "ratio": 1, + "keywords": [ + "learning", + "cards", + "sub-issues" + ] + }, + { + "level": 2, + "title": "Managing Issues (for Maintainers and Triagers)", + "status": "missing", + "ratio": 0.25, + "keywords": [ + "managing", + "issues", + "maintainers", + "triagers" + ] + }, + { + "level": 3, + "title": "Closing an issue", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "closing", + "issue" + ] + }, + { + "level": 3, + "title": "Reopening a closed issue", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "reopening", + "closed", + "issue" + ] + }, + { + "level": 3, + "title": "Assigning an issue", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "assigning", + "issue" + ] + }, + { + "level": 3, + "title": "Changing labels", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "changing", + "labels" + ] + }, + { + "level": 3, + "title": "Transferring or deleting an issue", + "status": "missing", + "ratio": 0.3333333333333333, + "keywords": [ + "transferring", + "deleting", + "issue" + ] + }, + { + "level": 3, + "title": "Learning Cards: Managing Issues", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "learning", + "cards", + "managing", + "issues" + ] + }, + { + "level": 2, + "title": "The \"good first issue\" Label - Your Entry Point", + "status": "covered", + "ratio": 1, + "keywords": [ + "good", + "first", + "issue", + "label", + "entry", + "point" + ] + }, + { + "level": 3, + "title": "Learning Cards: The \"good first issue\" Label", + "status": "covered", + "ratio": 1, + "keywords": [ + "learning", + "cards", + "good", + "first", + "issue", + "label" + ] + }, + { + "level": 2, + "title": "Accessibility-Specific Issue Writing Tips", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "accessibility-specific", + "issue", + "writing", + "tips" + ] + }, + { + "level": 3, + "title": "Example of a well-filed accessibility issue", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "example", + "well-filed", + "accessibility", + "issue" + ] + }, + { + "level": 2, + "title": "What happened", + "status": "covered", + "ratio": 1, + "keywords": [ + "happened" + ] + }, + { + "level": 2, + "title": "What I expected", + "status": "covered", + "ratio": 1, + "keywords": [ + "expected" + ] + }, + { + "level": 2, + "title": "How to reproduce", + "status": "missing", + "ratio": 0, + "keywords": [ + "reproduce" + ] + }, + { + "level": 2, + "title": "Environment", + "status": "missing", + "ratio": 0, + "keywords": [ + "environment" + ] + }, + { + "level": 2, + "title": "Additional context", + "status": "partial", + "ratio": 0.5, + "keywords": [ + "additional", + "context" + ] + }, + { + "level": 3, + "title": "Learning Cards: Accessibility-Specific Issue Writing", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "learning", + "cards", + "accessibility-specific", + "issue", + "writing" + ] + }, + { + "level": 2, + "title": "Writing Effective Issues", + "status": "partial", + "ratio": 0.6666666666666666, + "keywords": [ + "writing", + "effective", + "issues" + ] + }, + { + "level": 3, + "title": "Bug Report Structure", + "status": "covered", + "ratio": 1, + "keywords": [ + "bug", + "report", + "structure" + ] + }, + { + "level": 3, + "title": "Feature Request Structure", + "status": "covered", + "ratio": 1, + "keywords": [ + "feature", + "request", + "structure" + ] + }, + { + "level": 3, + "title": "General Issue Writing Principles", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "general", + "issue", + "writing", + "principles" + ] + }, + { + "level": 3, + "title": "Before and After: A Vague Issue vs. a Clear Issue", + "status": "covered", + "ratio": 1, + "keywords": [ + "before", + "after", + "vague", + "issue", + "clear" + ] + }, + { + "level": 3, + "title": "Learning Cards: Writing Effective Issues", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "learning", + "cards", + "writing", + "effective", + "issues" + ] + }, + { + "level": 2, + "title": "Try It: File Your First Issue", + "status": "partial", + "ratio": 0.75, + "keywords": [ + "try", + "file", + "first", + "issue" + ] + }, + { + "level": 3, + "title": "Learning Cards: Filing Your First Issue", + "status": "partial", + "ratio": 0.8, + "keywords": [ + "learning", + "cards", + "filing", + "first", + "issue" + ] + } + ] +} diff --git a/podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.txt b/podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.txt new file mode 100644 index 0000000..5aa92d3 --- /dev/null +++ b/podcasts/logs/agentic-pilots/ep05-working-with-issues-gpt54.txt @@ -0,0 +1,303 @@ +[ALEX] +Welcome back. In this lesson, we are working with GitHub Issues. And even if the word issue sounds like it means something went wrong, that is not the only job these are doing. In a lot of projects, an issue is just the shared record for a piece of work. It can describe a bug, a question, a task, an idea, a request, or a reminder. What matters is that everyone can point to the same place, see the same context, and add to the conversation over time. + +[JAMIE] +So this is less problem list and more collaboration log? + +[ALEX] +Exactly. A good issue gives work a home. Instead of details getting lost in chat, email, or memory, the issue holds the title, the description, the updates, and the decisions. It becomes the place the team can return to. + +[JAMIE] +That helps, because a lot of learners see the Issues tab and assume, I must have broken something. + +[ALEX] +That reaction is common. In this workshop, think of issues as working notes that are visible to the whole project. Some will describe real bugs. Some will just describe something the team wants to do next. Both belong there. + +[PAUSE] + +[ALEX] +For this chapter, the workshop gives you a recommendation and a challenge. The recommendation is the core path: create your first issue, fill it in clearly, and interact with it the way a collaborator would. The challenge pushes a little further. If you want more practice, you can explore things like sub-issues, extra filtering, or alternative ways to work, including doing part of this locally with Git or the GitHub CLI. + +[JAMIE] +So nobody is being asked to master every advanced feature right away? + +[ALEX] +Right. The expected outcome is not know every issue feature. The expected outcome is simpler and more useful: you should be able to find the Issues area, understand what you are looking at, create an issue that another person can actually use, and participate in the follow-up conversation. + +[JAMIE] +That sounds like a realistic workshop target. + +[ALEX] +It is. And it also matches real team habits. Clear, usable issue writing helps other people move faster. It also helps future-you. + +[PAUSE] + +[ALEX] +Let us orient ourselves first. In a repository on GitHub, the Issues tab is one of the main navigation areas. If you use a mouse, you can select it from the top navigation. If you use a keyboard, tabbing through the repository navigation should eventually land on Issues, and screen readers will usually announce it as a tab or navigation item in the repository header area, depending on the page structure. + +[JAMIE] +And once you open it, what should people expect on the page? + +[ALEX] +Usually, an issue list page. That page has a few distinct parts. You will typically find controls for filtering and searching. You will see a button to create a new issue. And below that, you will see rows for existing issues. + +[JAMIE] +Those rows can be a little dense at first. + +[ALEX] +They can, so it helps to know what each row is trying to tell you. A row usually includes the issue title first, because that is the fastest signal about what the item is. You may also hear or see the issue number, whether it is open or closed, who opened it, and other metadata like labels, comments, or related work. If you are using a screen reader, move through the row carefully. The title link is usually the main entry point, but the surrounding text provides the status and context that help you decide whether this is the item you want. + +[JAMIE] +So if I am scanning the list, I am not just reading titles. I am also reading status. + +[ALEX] +Yes. The list is doing triage work for you. It helps you answer questions like: Is this still active? Is there already a conversation about the thing I was about to bring up? Does a label tell me this is documentation, accessibility, bug fixing, or enhancement work? + +[PAUSE] + +[ALEX] +Filtering and search matter a lot here. On active projects, the issue list can get crowded fast. Search lets you find terms inside issue titles and sometimes body text depending on how you search. Filters help you narrow by status, author, labels, assignees, and other properties. Even if you only learn a few filters today, that is enough to avoid duplicating work that already has an issue. + +[JAMIE] +That is an important point. Before creating a new issue, look to see whether someone already opened one. + +[ALEX] +Exactly. It is respectful to the team, and it keeps discussion from splitting into multiple places. If you are using a keyboard, spend a moment learning where the search field and filter controls are on the page. If you have low vision, zooming in or increasing browser text size can change the layout, so the controls may wrap or move. That is normal. Give yourself permission to slow down and re-scan the page structure. If you use a screen reader, headings, landmarks, and form fields are your friends here. They make the list page much easier to navigate than trying to read every item in sequence. + +[JAMIE] +That is a good workshop habit in general: do not fight the whole page if the page already has structure you can use. + +[ALEX] +Exactly right. + +[PAUSE] + +[ALEX] +Now, the create-your-first-issue flow. Once you are in the Issues area, you open the new issue form. Depending on the repository, you may see a simple blank form, or you may see templates that guide different kinds of requests. For this lesson, the important thing is the writing, not memorizing every repository-specific screen. + +[JAMIE] +What makes a first issue good enough? + +[ALEX] +Two things immediately: a useful title and a useful body. The title should help someone understand the topic before they even open the issue. Not perfect. Just specific enough to be informative. Fix stuff is not helpful. Clarify setup instructions for Windows learners is much better. Add alt text to lesson screenshots is much better. A clear title reduces guesswork. + +[JAMIE] +And the body is where you give the rest of the picture. + +[ALEX] +Yes. The body should answer the natural follow-up questions. What are you seeing? What are you trying to do? Why does it matter? If this is a task, what outcome are you aiming for? If this is a problem, how can someone else recognize it? If there is evidence, include it. + +[JAMIE] +What counts as evidence here? + +[ALEX] +Anything that helps another person understand the situation without recreating all of your steps from scratch. That could be a short description of what happened, the exact text of an error message, a screenshot if that is appropriate, or the steps you took before the issue appeared. For accessibility-related issues, evidence might also include what assistive technology you used, what browser or device you were on, and what behavior made the experience difficult. + +[JAMIE] +That last part matters. This page is inaccessible is too vague to act on. + +[ALEX] +Right. A better issue body gives someone a path to investigate. For example: Using keyboard only, I could reach the navigation but not the submit button. Or: With screen reader reading mode, the issue rows were announced, but the status was not obvious until I moved line by line. That is actionable. + +[PAUSE] + +[JAMIE] +Let me ask a beginner question. How polished does the body need to be? Some learners freeze because they think they need to write like a product manager. + +[ALEX] +You do not need a polished memo. You need enough clarity for another person to understand the work. A short, direct issue is often better than a long vague one. If you can answer who, what, where, and why this matters, you are usually in good shape. + +[JAMIE] +So if the title is specific and the body gives context and evidence, that is already a solid issue. + +[ALEX] +Yes. And this workshop is trying to build that habit. Not perfection. Usability. + +[PAUSE] + +[ALEX] +After the issue exists, the collaboration part continues in comments. Comments let people ask questions, add updates, attach evidence, suggest approaches, or record decisions. This is where you see why issues are records, not just forms. + +[JAMIE] +And this is where mentions come in too. + +[ALEX] +Yes. If you type an at-sign and a username, GitHub can notify that person. Mentions matter because they connect the conversation to the right people. If you need input from a maintainer, a reviewer, or a teammate, an @mention brings them into the thread directly rather than hoping they happen to notice the issue later. + +[JAMIE] +So it is not just tagging for the sake of tagging. It is routing attention. + +[ALEX] +That is a good way to put it. Mentions help route attention. They are especially useful when a conversation reaches a point where a specific person needs to review, answer, or approve something. + +[JAMIE] +Any caution there? + +[ALEX] +Use mentions intentionally. If you mention five people every time, it stops being helpful. Mention the person who is genuinely relevant to the next step. + +[JAMIE] +And if someone mentions you, the expectation is that the issue is now your place to respond, not a private side conversation somewhere else. + +[ALEX] +Exactly. Keeping the response in the issue preserves the shared record. + +[PAUSE] + +[ALEX] +Some projects also use sub-issues. These are optional, and you do not need them for every task. They help when one larger piece of work naturally breaks into smaller, trackable parts. Imagine an issue for improving a lesson page. That larger issue might be easier to manage if it links to separate smaller issues for updating screenshots, fixing keyboard focus order, and revising the written instructions. + +[JAMIE] +So the parent issue says, here is the broader job, and the sub-issues capture the individual chunks? + +[ALEX] +That is the idea. It helps when work has multiple contributors, or when progress is easier to track as a set of smaller outcomes. But for a simple task, making sub-issues can create more overhead than value. Use them when they make the work clearer, not when they just make the project look more complicated. + +[JAMIE] +That distinction helps. Optional means optional. + +[ALEX] +Exactly. + +[PAUSE] + +[ALEX] +The chapter also expects some kind of evidence submission from you as you work through the exercise. In workshop terms, that usually means showing what you created or what you observed. It might be the issue you opened, a screenshot of the issue page, a link to the issue, or a short note describing the comments or mentions you added. + +[JAMIE] +So the evidence is not busywork. It proves you can move through the flow. + +[ALEX] +Right. It gives the instructor, or your future self, something concrete to check. Did you open the issue? Did you write a useful title? Did you add enough context? Did you interact with the conversation? The evidence should make those answers visible. + +[JAMIE] +And that ties back to the expected outcomes. + +[ALEX] +Yes. By the end, you should be able to say: I know where issues live in a repository. I can read the list without feeling lost. I can create an issue that is specific and useful. I can comment on an issue. I understand why @mentions matter. I know when sub-issues might help. And I can document what I did. + +[PAUSE] + +[JAMIE] +Let us talk about getting stuck, because this is one of those places where people can get blocked by small things. Maybe they cannot find the right button. Maybe they are unsure whether their issue is good enough. Maybe the page layout looks different from the lesson. + +[ALEX] +That is exactly the kind of friction this chapter anticipates. If you get stuck, the recovery guidance is simple and practical. First, check whether you are in the right repository area. It sounds obvious, but a lot of confusion comes from being in Pull Requests, Discussions, or Code when you meant to be in Issues. Second, look for an existing issue before opening a new one, because the answer or context may already be there. Third, if the layout differs from the screenshots or lesson text, focus on the function of the page, not matching the page pixel for pixel. + +[JAMIE] +Meaning: find the list, the search and filter controls, and the create button, even if the interface has shifted around. + +[ALEX] +Exactly. And if writing the issue body feels hard, reduce the problem. Write the title first. Then answer one question at a time: what is happening, what did I expect, and what evidence can I provide? That is often enough to break the freeze. + +[JAMIE] +What if someone is using assistive tech and the obstacle itself is access? + +[ALEX] +Then document that directly. If keyboard navigation is trapping you, say so. If a control is hard to identify at high zoom, say so. If a screen reader announces the page in a confusing order, say so. Accessibility blockers are real blockers, and naming them clearly is part of the work, not a distraction from it. + +[JAMIE] +That is worth hearing out loud. + +[ALEX] +It is. In this chapter, accessibility is not an extra topic off to the side. It is integrated into how you use the tool. A keyboard user may navigate the issue list differently from a mouse user. A low-vision learner may rely on zoom, contrast settings, or careful scanning of headings and labels. A screen-reader user may need to move by landmarks, headings, links, and form fields rather than by visual grouping. All of those are valid working methods, and the lesson should support them. + +[PAUSE] + +[JAMIE] +You mentioned multiple working styles. That seems to be a broader learning pattern in this course. + +[ALEX] +Yes. One of the learning moments in this chapter is that collaboration tools are not just about the feature set. They are about finding a way of working that fits how you process information and move through interfaces. Some people understand issues best by opening one and reading it top to bottom. Some understand better by scanning the list first, noticing patterns in titles and labels, and then opening a few examples. Some want to work entirely in the browser. Others prefer local tools. + +[JAMIE] +That is where the learning cards idea comes in, right? Different paths for different learners. + +[ALEX] +Exactly. Think of the learning cards as multiple valid ways to practice the same outcome. One learner might follow the browser path closely and focus on visual navigation. Another might lean into keyboard access and screen-reader structure. Another might prefer local Git or the GitHub CLI because command-line workflows are easier for them to repeat and reason about. + +[JAMIE] +Let us say more about that last group, because a lot of people are surprised that issues are not browser-only. + +[ALEX] +Right. The lesson centers the GitHub interface, because that is the most universal entry point, but there is also a local Git and GitHub CLI alternative. Local Git itself does not manage issues as a core feature, but the GitHub CLI can. If you already work comfortably in a terminal, you can view, create, and comment on issues there. That can be useful for keyboard-focused workflows, automation, or just personal preference. + +[JAMIE] +So the principle stays the same even if the interface changes. + +[ALEX] +Exactly. Whether you create the issue in the web UI or through the GitHub CLI, the same standards apply. The title still needs to be clear. The body still needs context and evidence. Comments still carry the collaboration forward. Mentions still matter because they notify the right people. + +[PAUSE] + +[JAMIE] +I want to go back to the issue list one more time, because it is easy to underestimate how much information is packed into that page. What should learners actively practice noticing? + +[ALEX] +Notice the status first: open or closed. Then notice the title and whether it sounds like your topic. Then check the supporting details: labels, number of comments, who opened it, and any clues about scope or urgency. If you are using search and filters, practice narrowing the list before opening items at random. That is a real project skill. It saves time and prevents duplicate reporting. + +[JAMIE] +And if someone is using a screen reader, that same skill becomes listen for the signals that help you choose the right issue. + +[ALEX] +Exactly. Instead of visually skimming rows, you are listening for the row details that tell you whether to open that issue. It is the same decision process, just through a different access method. + +[JAMIE] +What about low-vision users on a busy issue page? + +[ALEX] +Use the browser tools that make the page readable to you. Zoom in. Increase text size. Use your preferred contrast settings. If the page becomes visually crowded, move section by section instead of trying to hold the full layout in view. The issue title, issue body, comments, and metadata are all meaningful, but you do not need to absorb them at once. + +[PAUSE] + +[ALEX] +Here is the deeper learning pattern underneath all of this: collaboration works better when information is discoverable, specific, and shared in the place where future work will happen. That is why issues matter. They reduce ambiguity. They make conversations durable. They help teams coordinate across time. + +[JAMIE] +And that is also why the writing quality matters more than people think. + +[ALEX] +Yes. A vague issue costs everyone time. A clear issue invites useful action. This is not about sounding formal. It is about making the work legible to other people. + +[JAMIE] +That is a good workshop sentence: make the work legible. + +[ALEX] +It applies everywhere. Good issue titles make the list legible. Good issue bodies make the task legible. Good comments make decisions legible. Mentions make responsibility legible. Evidence makes progress legible. + +[PAUSE] + +[JAMIE] +If someone completes this chapter and still feels awkward using issues, should they worry? + +[ALEX] +No. The goal is familiarity, not fluency in one session. If you can find the Issues tab, understand the list page, create a reasonable issue, add a comment, use a mention when appropriate, and explain what you did, you are on track. The rest comes from repetition. + +[JAMIE] +And repetition can happen in different styles. + +[ALEX] +Exactly. You might practice in the browser. You might practice with the GitHub CLI. You might focus on keyboard navigation one day and on writing clearer issue bodies the next. Those are all valid ways to build the skill. + +[JAMIE] +One last practical question. If a learner is unsure whether to open an issue, what should guide the decision? + +[ALEX] +Ask whether the work would benefit from a shared record. If the answer is yes, an issue is probably a good fit. If the topic needs context, follow-up, or visibility, an issue helps. If it is just a private note to yourself and no collaboration is needed, maybe not. But in most project settings, making work visible is a strength, not a burden. + +[PAUSE] + +[ALEX] +So, as you move through the exercise, keep the shape of the lesson in mind. Find the Issues area. Learn the page enough to orient yourself. Read the issue rows for meaning, not just titles. Use search and filters before creating something new. Write a title that tells the truth about the work. Write a body that gives context and evidence. Use comments to keep the collaboration in the open. Use @mentions to bring in the right person when needed. Treat sub-issues as optional structure for larger work. Capture evidence of what you did. And if you hit friction, use the recovery steps instead of assuming you are failing. + +[JAMIE] +That is a much calmer way to approach it. + +[ALEX] +That is the point. GitHub Issues are not a test of whether you already know how teams work. They are one of the tools teams use to learn how to work together. + +[JAMIE] +And if you can leave a clear trail for the next person, you are already doing meaningful collaboration. + +[ALEX] +Exactly. That is the lesson. \ No newline at end of file diff --git a/podcasts/logs/agentic-pilots/ep05-working-with-issues.packet.json b/podcasts/logs/agentic-pilots/ep05-working-with-issues.packet.json new file mode 100644 index 0000000..a523ee3 --- /dev/null +++ b/podcasts/logs/agentic-pilots/ep05-working-with-issues.packet.json @@ -0,0 +1,391 @@ +{ + "generatedAt": "2026-05-13T01:40:09.514Z", + "kind": "companion", + "slug": "ep05-working-with-issues", + "title": "Episode 5: Working with Issues", + "description": "Filing, searching, filtering, commenting on, and managing GitHub issues.", + "transcriptPath": "S:\\code\\git-going-with-github\\podcasts\\scripts\\chapters\\ep05-working-with-issues.txt", + "chapterPlanPath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\chapters\\ep05-working-with-issues-chapters.json", + "transcriptText": "[ALEX]\nWelcome back to Git Going with GitHub. This is episode 5: Working with Issues. I am Alex, and today we are turning Working with Issues from a list of instructions into a working mental model.\n\n[JAMIE]\nAnd I am Jamie. I will stop us whenever the instructions sound simple on paper but might feel different with a keyboard and screen reader.\n\n[PAUSE]\n\n[ALEX]\nFiling, searching, filtering, commenting on, and managing GitHub issues. That is the surface description. Underneath it, we are building judgment: where to focus, what to ignore, and how to verify the result.\n\n[JAMIE]\nSo we are not using the audio as a shortcut around learning. We are using it to make the learning easier to enter.\n\n[ALEX]\nYes. A good audio lesson gives someone enough context to try the work with confidence, even before they open the written material.\n\n[PAUSE]\n\n[JAMIE]\nOkay, set the room for us. What are we walking into?\n\n[ALEX]\nFiling, Managing, and Participating in GitHub Issues: Issues are where open source collaboration begins. The next useful detail is concrete: everything from finding the right issue to file a perfect bug report - all with your keyboard and screen reader.\n\n[ALEX]\nA solid issue habit is to read the title, the body, and the timeline before acting. You are listening for the requested action, the missing evidence, and the person who needs a response.\n\n[ALEX]\nThe next layer is this. Here is the learner-facing version. Chapter 5 is the first issue-based challenge chapter with short, confidence-building tasks. Put another way, it supports Challenge 2 (File Your First Issue) and Challenge 3 (Join the Conversation). A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[ALEX]\nHere are the anchors worth keeping. There are 2 core challenges plus one optional extension. Each challenge should take under 10 minutes. The evidence is issue comments and issue metadata. The pattern is claim - act - confirm.\n\n[JAMIE]\nWhat does the learner do first, second, and then after that?\n\n[ALEX]\nThis is the move inside Chapter 5 Challenge Set: chapter 5 focuses on issue skills. That matters in practice: You do NOT need to create a branch or edit any files for these challenges.\n\n[ALEX]\nWalk it in order: Create your first issue - file a new issue with a clear title and description; Comment and @mention - leave a comment on a classmate's issue and tag them with an @mention; and Optional extension: Add a sub-issue - break a larger issue into smaller, trackable pieces if your repository has sub-issues enabled. Each step should leave a trace you can name.\n\n[JAMIE]\nThat feels much more doable when you say it as one move.\n\n[ALEX]\nRight. The magic is not speed. The magic is knowing what changed and why it matters.\n\n[PAUSE]\n\n[JAMIE]\nTurn that into a path someone can follow.\n\n[ALEX]\nAnchor this part on Challenge 2 Step-by-Step: Create Your First Issue. File a new issue in your Learning Room repository with a specific title and a meaningful description. This is the part to say slowly: Issues are the prompts that wake up AI.\n\n[ALEX]\nFor a learner, the useful signals are concrete. \"Agent Request: Add missing contributor background paragraph in welcome.md\". \"Keyboard shortcuts table has incorrect NVDA modifier key\". \"Setup guide link to accessibility settings is broken\". What the problem is or what content is missing.\n\n[ALEX]\nThink of this as 4 checks: Open your Learning Room repository in your browser; Navigate to the Issues tab (press G then I to jump there with keyboard shortcuts, or find the \"Issues\" link in the repository navigation); Activate the New issue button; and If a template picker appears, select Open a blank issue (or choose a template if one fits). If one step does not match what you hear, stop there and re-orient.\n\n[JAMIE]\nWhat is the ordered workflow?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is in the Title field, type a clear, specific title (at least 12 characters). Step two is in the Body field, write a meaningful description (at least 80 characters). Step three is activate Submit new issue. Step four is copy the issue URL or note the issue number (for example, 150). You will reference this later. That is the rhythm: orient, act, verify, continue.\n\n[JAMIE]\nGive me the sequence, because order matters here.\n\n[ALEX]\nThe reason this matters is simple: leave a comment on another student's issue and use an @mention to notify them. The listener should be able to check this: the Issues tab of your Learning Room repository on GitHub.com.\n\n[ALEX]\nThe parts worth keeping in working memory are these. \"@classmate I can confirm this - the link in setup-guide.md goes to a 404 page.\". \"@classmate Good catch! I think the correct shortcut is Insert+F7, not Insert+F5.\". \"@classmate I'd suggest adding the paragraph right after the 'Who Can Contribute' heading.\".\n\n[ALEX]\nThe path is straightforward once it is named. Step one is open the Issues tab in your Learning Room repository. Step two is find an issue created by a classmate (look for recent open issues, or use a facilitator-provided peer-simulation issue). Step three is open the issue by activating its title link. Step four is read the issue description to understand what they reported. That is the rhythm: orient, act, verify, continue.\n\n[JAMIE]\nHow would you walk the room through that step by step?\n\n[ALEX]\nFirst, scroll to the comment box at the bottom of the issue. Then, write a helpful comment that @mentions the issue author by username. After that, activate the Comment button (or press Ctrl+Enter). That small check between steps is what makes the workflow reliable.\n\n[ALEX]\nThe useful habit is simple: orient, act, verify, then continue. That pause between action and trust is part of the work.\n\n[JAMIE]\nLet's pause on Optional Extension Step-by-Step: Add a Sub-Issue. What should a learner take away from it?\n\n[ALEX]\nDo not treat Optional Extension Step-by-Step: Add a Sub-Issue as decoration. Break a larger issue into smaller, trackable pieces using GitHub's sub-issue feature. That is not trivia. the issue you created in Challenge 2 (or any open issue you have permission to edit). The workshop is closer to rehearsal than lecture. You hear the move, try the move, and then check what changed.\n\n[ALEX]\nOn the ground, that means a few things. Sub-issue: \"Add alt text to welcome banner image\". Sub-issue: \"Fix heading hierarchy in Getting Started section\".\n\n[ALEX]\nFirst, open the issue you created in Challenge 2. Then, look for the Sub-issues section in the issue sidebar (right side on desktop). If you do not see it, look for an Add sub-issue button or the Create sub-issue option below the issue description. After that, activate Add sub-issue and choose Create new sub-issue. Finally, give the sub-issue a clear title that describes one specific piece of the parent issue. For example, if the parent is \"Fix accessibility in welcome.md\". That small check between steps is what makes the workflow reliable.\n\n[JAMIE]\nBefore we leave Optional Extension Step-by-Step: Add a Sub-Issue, what is the practical point?\n\n[ALEX]\nStart here: Add a short description and activate Create. Then: The sub-issue now appears nested under the parent issue with a progress indicator. The sequence works because every action has a confirmation.\n\n[PAUSE]\n\n[JAMIE]\nWhat should the learner prove to themselves after each small task?\n\n[ALEX]\nIf the interface shifts, Completing Chapter 5: Submit Your Evidence is still useful because when you have finished the Chapter 5 issue challenges, go to your assigned Challenge 2 or Challenge 3 issue and post a comment with your evidence. For someone navigating by keyboard or screen reader, this detail matters: Replace [number] with the actual issue numbers.\n\n[ALEX]\nThis is where the talk moves from concept to action. Expected Outcomes has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThe room should hear these as checkpoints. Student can create an issue with a clear title and description. Student can communicate in issue threads using @mentions. Student can organize work by breaking issues into sub-issues.\n\n[JAMIE]\nNow it sounds like a workflow instead of a wall of instructions.\n\n[ALEX]\nThat is where confidence comes from: not from never getting lost, but from knowing how to recover.\n\n[JAMIE]\nLet's pause on If You Get Stuck. What should a learner take away from it?\n\n[ALEX]\nIf You Get Stuck has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThink of this as 4 checks: Can't find a classmate's issue? Filter the Issues tab by is:open and look for recent ones; @mention not working? Make sure you type @ immediately followed by the username with no space; Sub-issue option not visible? Ask a facilitator - the feature may need to be enabled for the repository; and Still stuck? Ask a facilitator for a direct issue link. Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave If You Get Stuck, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is finished but not sure you did it right? Compare your work against the Challenge 2 reference solution or the Challenge 3 reference solution. The point is not speed; the point is never losing your place.\n\n[PAUSE]\n\n[ALEX]\nBefore the learner moves on. This part earns its place because issues are collaborative spaces, not just task lists. That gives the learner a foothold: an @mention tells someone \"I need your attention here.\" Sub-issues turn vague tasks into clear checklists. That is the difference between following directions and owning the workflow.\n\n[JAMIE]\nLet's pause on Learning Pattern Used in This Chapter. What should a learner take away from it?\n\n[ALEX]\nLearning Pattern Used in This Chapter has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nFirst, start with a small, safe action (create an issue). Then, practice communication in public issue threads (@mention a peer). After that, organize work into smaller pieces (sub-issues). Finally, leave clear evidence in the issue timeline. Each step should leave a trace you can name.\n\n[JAMIE]\nBefore we leave Learning Pattern Used in This Chapter, what is the practical point?\n\n[ALEX]\nStart here: Build momentum for file editing and PR work in Chapter 6. If one step does not match what you hear, stop there and re-orient.\n\n[ALEX]\nNow slow down for the part people usually miss. Here is the learner-facing version. This chapter provides learning cards: expandable blocks that offer perspective-specific guidance for different ways of working. Put another way, not every card appears at every step.\n\n[PAUSE]\n\n[JAMIE]\nWhat should they understand before typing anything?\n\n[ALEX]\nThis is the move inside Local Git Alternative: Working from Your Clone: if you cloned the learning-room in Block 0 and prefer working locally. That matters in practice: During Block 0 you cloned the Learning Room repository to your computer.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like cd /Documents/learning-room or wherever you cloned it; git status should show \"On branch main\". List your assigned challenge issues; gh issue list --assignee @me --label challenge; View a specific issue in the terminal; gh issue view 42; Leave a comment on an issue; gh issue comment 42 --body \"I'd like to try this!\"; Create a new issue interactively; gh. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nThat is the kind of detail that keeps a screen reader user oriented.\n\n[ALEX]\nYes. The named thing - the heading, tab, field, branch, or button - is the handhold.\n\n[ALEX]\nA solid Git habit is to know which branch you are on, what changed, and what confirmation you expect before you run the next command.\n\n[ALEX]\nHere is the moment where the page starts to make sense. Anchor this part on What Is a GitHub Issue? An issue is a discussion thread attached to a repository. This is the part to say slowly: Every issue has a number ( 42), a state (Open or Closed), a title, a description, and a comment thread. The durable skill is not memorizing one screen. It is knowing how to find your footing when the screen changes.\n\n[ALEX]\nListen for the small confirmations in this list. Bug reports - \"This feature doesn't work when using a screen reader\". Feature requests - \"It would help if the submit button had an accessible label\". Questions - \"How do I configure X for Y use case?\". Tasks - \"Update the README with screen reader instructions\".\n\n[JAMIE]\nLet's pause on From a repository page. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: click the Issues tab in the repository navigation bar below the repository name. The listener should be able to check this: The tab shows the open issue count (e.g., \"Issues · 14\").\n\n[ALEX]\nThe path is straightforward once it is named. Step one is press D to navigate to the \"Repository navigation\" landmark. Step two is press K or Tab to move through the tab links. Step three is find \"Issues\" - it will be announced with the count: \"Issues, 14 open\". Step four is press Enter to open the Issues tab. The sequence works because every action has a confirmation.\n\n[JAMIE]\nBefore we leave From a repository page, what is the practical point?\n\n[ALEX]\nFirst, vO+U → Landmarks → navigate to \"Repository navigation\". Then, vO+Right or Quick Nav K to move through tab links. After that, find \"Issues\" - VoiceOver announces the count: \"Issues 14\". Finally, vO+Space to activate the Issues tab. Keep it that plain: know where you are, make the move, check the result.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like gh issue list. gh issue list --label \"good first issue\"; gh issue list --assignee @me; gh issue list --state closed. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[PAUSE]\n\n[ALEX]\nThe next point gives the learner a handle. Do not treat Direct URL as decoration. Navigate directly: https://github.com/[owner]/[repo]/issues.\n\n[JAMIE]\nWhat would you say to someone who is already bracing for this to be too much?\n\n[ALEX]\nLearning Cards: Navigating to the Issues List has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nA few details make that real. Press D to jump to the \"Repository navigation\" landmark, then K or Tab to find the Issues link -- this is faster than arrowing through the entire page. The Issues tab announces its open count (\"Issues, 14 open\"), giving you an instant sense of project activity without loading the list. Use gh issue list in the terminal to bypass browser navigation entirely; pipe through --label or --assignee @me to pre-filter results. The Issues tab count badge may be small at default zoom; at 200%+ the tab text reflows but the count remains visible next to the word \"Issues\". Bookmark the direct URL pattern (github.com/owner/repo/issues) to skip repository page navigation altogether. In high-contrast mode, the active tab is indicated with an underline using system highlight color, not just a subtle background change.\n\n[ALEX]\nHold that next to this. Put Page structure into plain language. Quick orientation tip: Press NVDA+F7 (or VO+U on macOS) to open a list of all headings, links, form fields, and buttons on the page. The useful version is: This is often faster than tabbing through many elements and helps you understand the full page structure before diving in. The interface gets easier when it becomes a set of named places instead of a wall of controls.\n\n[JAMIE]\nSo the learner is not behind if they stop there and check the page.\n\n[ALEX]\nYes. Pausing to verify is not a detour; it is how you keep control of the workflow.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on How to read the issue list. What should a learner take away from it?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. The issues list shows each issue as a row with its title, labels, number, assignee avatars, and comment count. That is the difference between guessing and knowing: Closed issues show a purple merged/closed badge.\n\n[ALEX]\nThat shows up in the workshop in a few specific ways. Issue titles are the largest text in each row and remain readable at 200%+ zoom. Label badges use colored backgrounds with text inside. In Windows High Contrast mode, labels display with system border colors and readable text rather than colored backgrounds. The Open and Closed toggle links above the list let you switch views. The active toggle is bold or underlined. The comment count icon (a speech bubble) may be small at high zoom. It appears to the right of each issue row. Hover to see \"N comments\" tooltip.\n\n[ALEX]\nThink of this as 4 checks: Press D to reach the \"Search Results List\" landmark; Press 3 (h3) to navigate by issue titles - each issue title is an h3 link; Press I to move between list items if you want more detail per item; and Press Enter on a title to open that issue. Each step should leave a trace you can name.\n\n[JAMIE]\nBefore we leave How to read the issue list, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is vO+U → Landmarks → navigate to \"Search Results List\". Step two is vO+Down to read through items. Step three is h (with Quick Nav on) or VO+U → Headings to jump by issue title. If one step does not match what you hear, stop there and re-orient.\n\n[ALEX]\nThat connects to another useful point. This part earns its place because when you navigate to an issue in the list, your screen reader will announce (in some order).\n\n[ALEX]\nHere is what that changes in practice. Issue title (as a link). Issue number ( 42). Labels (e.g., \"bug, good first issue\"). Who opened it and when (\"Opened 3 days ago by username\"). Number of comments (\"5 comments\").\n\n[JAMIE]\nWhat is the one idea that makes the next few steps less mysterious?\n\n[ALEX]\nLearning Cards: The Issues List Page has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThese are the details that keep the idea from floating away. Press D to jump to the \"Search Results List\" landmark, then press 3 to navigate issue titles (each is an H3 link). Press I to move between individual list items if you want full detail per issue (number, labels, author, age). After applying a filter, the issue list updates silently; press 3 again to re-navigate the updated list from the top. Issue titles are the largest text per row and stay readable at 200%+ zoom; labels appear as small colored badges to the right of each title. The Open/Closed toggle links are near the top of the list; the active state is bold or underlined depending on your theme. If the comment count icon (speech bubble) is too small at your zoom level, hover over it for a tooltip showing the exact count.\n\n[PAUSE]\n\n[ALEX]\nHere is the practical turn. Here is the learner-facing version. Filtering lets you narrow the list to find the right issue quickly. A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[JAMIE]\nLet's pause on Using the search/filter bar. What should a learner take away from it?\n\n[ALEX]\nUsing the search/filter bar has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nWalk it in order: Press F or E to jump to the filter input field (or navigate from the landmark); Switch to Focus Mode (NVDA+Space / Insert+Z) if not already in it; Type your filter or search query; and Press Enter to apply. The sequence works because every action has a confirmation.\n\n[JAMIE]\nThat is a useful checkpoint before anyone starts pressing keys.\n\n[ALEX]\nExactly. Checkpoints turn uncertainty into information.\n\n[JAMIE]\nLet's pause on Using the filter buttons. What should a learner take away from it?\n\n[ALEX]\nAnchor this part on Using the filter buttons. Above the issue list, there is an actions toolbar with filter buttons for Labels, Milestones, Assignees, etc. This is the part to say slowly: The filter buttons do not indicate the current filter state.\n\n[ALEX]\nThat becomes easier when you listen for these cues. The Label, Milestone, and Assignee buttons may wrap to a second row. Each button opens a dropdown with searchable options. Dropdown menus from filter buttons can extend below the visible viewport at high zoom. Scroll within the dropdown to see all options. Type in the search field at the top of each dropdown to narrow the list (for example, type \"accessibility\" in the Label dropdown). In Windows High Contrast mode, the selected filter values are indicated with a checkmark icon and system highlight color, not just a background color change.\n\n[ALEX]\nThink of this as 4 checks: Press Tab from the search bar (or Shift+Tab from the issue list) to reach the actions toolbar; Press ←/→ to move between toolbar options (Label, Milestone, Assignee, Sort); Press Enter to open the selected dropdown; and Use ↑/↓ to navigate options in the dropdown. Keep it that plain: know where you are, make the move, check the result.\n\n[JAMIE]\nBefore we leave Using the filter buttons, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is press Enter or Space to select. Step two is press Escape to close (filter applies immediately). Step three is tab forward from the search bar to reach the filter buttons, or use Quick Nav to find them. Step four is vO+Left/Right to move between Label, Milestone, Assignee, Sort buttons. Pause after each step and listen for the confirmation before moving on.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Filter by label; gh issue list --label \"accessibility\"; Combine filters; gh issue list --label \"good first issue\" --assignee @me; Filter by milestone; gh issue list --milestone \"Hackathon Day 1\"; Search with keywords; gh issue list --search \"screen reader\". Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[PAUSE]\n\n[JAMIE]\nIf I am listening before the workshop starts, what should settle in my mind first?\n\n[ALEX]\nThe reason this matters is simple: the two state links \"Open\" and \"Closed\" appear near the top of the issue list. The listener should be able to check this: Press K to navigate links until you find them, or look for them as buttons near the search bar.\n\n[ALEX]\nAnother way to ground it. Learning Cards: Filtering and Searching Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nIf someone is taking notes, this is the short list. Switch to Focus Mode (NVDA+Space) before typing in the filter bar; switch back to Browse Mode after pressing Enter to read the filtered results. The filter bar does not announce how many results remain after filtering; press H to jump to the issue list heading, then listen for the count in the heading text. Combine gh issue list flags (e.g., --label \"accessibility\" --assignee @me) for instant filtered results without navigating dropdown menus. Filter dropdown menus can extend below the viewport at high zoom; scroll within the dropdown or type in the search field at the top of each dropdown to narrow options. After applying a filter, verify it took effect by checking the search bar text -- it updates to show active conditions like is:open label:accessibility. The Ctrl+/ (Windows) or Cmd+/ (Mac) shortcut focuses the search bar instantly, avoiding the need to scroll up to find it.\n\n[JAMIE]\nWhere do you want a learner to place their attention here?\n\n[ALEX]\nIf the interface shifts, Landing on an issue page is still useful because when you open an issue, the page structure is.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Reading the issue description. What should a learner take away from it?\n\n[ALEX]\nPut Reading the issue description into plain language. Browse Mode recommended: The issue detail page is primarily text-based. The useful version is: Stay in Browse Mode (not Focus Mode) for reading - it gives you full heading (H), section (D), and link (K) navigation throughout the page.\n\n[ALEX]\nWalk it in order: Press 2 to reach the \"Description\" heading; Press ↓ to read the content line by line,; and Use NVDA+↓ (NVDA say all) to have it read continuously. If one step does not match what you hear, stop there and re-orient.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like View issue in terminal (renders Markdown); gh issue view 42; Open the issue in your browser instead; gh issue view 42 --web; View just the comments; gh issue view 42 --comments. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nI like that because it gives people permission to slow down.\n\n[ALEX]\nThat is the goal. We want the page to feel explorable, not fragile.\n\n[JAMIE]\nGive me the version that sounds like an instructor, not a manual.\n\n[ALEX]\nThe teaching point here is not the label; it is the move. Each comment in the thread is marked as an h3. That is the difference between guessing and knowing: Other timeline events (label added, PR linked, issue closed) appear between comments in the activity stream.\n\n[ALEX]\nThese are the pieces that turn the idea into a usable move. Commenter's username. Timestamp (\"2 days ago\"). Body text. Reactions (if any - announced as a button with an emoji and count).\n\n[ALEX]\nPut that beside the next piece. Learning Cards: Reading an Issue has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThe useful version is not abstract; it sounds like this. Press 1 to hear the issue title, then 2 to reach \"Description\" and \"Activity\" headings, and 3 to jump between individual comments. Stay in Browse Mode for reading; only switch to Focus Mode (NVDA+Space) when you need to type in the comment box. Press D to jump to the \"Add a comment\" landmark at the bottom of the page to skip directly to the reply area. The issue title is the largest text on the page, followed by an Open/Closed badge in green or purple. Comment blocks have a subtle border and a grey header bar showing the author's avatar and timestamp; zoom in on the header to identify commenters. The sidebar (Labels, Assignees, Milestone) is on the right at desktop width; at high zoom it may move below the main content.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Step-by-step. What should a learner take away from it?\n\n[ALEX]\nStep-by-step: To close the issue while commenting: click the arrow on the Close issue button and choose Close with comment. The next useful detail is concrete: Low vision users (zoom, high contrast).\n\n[ALEX]\nFirst, scroll to the bottom of the issue page. Then, click in the Leave a comment text area. After that, type your comment (Markdown is supported - use the toolbar buttons above the text for bold, italic, code, etc.). Finally, optionally click Preview to see how it will render. The sequence works because every action has a confirmation.\n\n[JAMIE]\nBefore we leave Step-by-step, what is the practical point?\n\n[ALEX]\nStart here: Click the green Comment button to post. Then: Scroll to the bottom to find the Leave a comment text area. At 200%+ zoom, this may require significant scrolling past the timeline. Next: The text area expands as you type. The formatting toolbar above it (bold, italic, code, etc.) wraps at high zoom but remains functional. Last: The Preview tab next to Write lets you check Markdown rendering before posting. Keep it that plain: know where you are, make the move, check the result.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Interactive: opens your default editor ($EDITOR) to write the comment; gh issue comment 42; Inline: provide the comment text directly; gh issue comment 42 --body \"Thanks for reporting this. I can reproduce the issue with NVDA + Chrome.\". Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[ALEX]\nNow shift from knowing the term to using it. Here is the learner-facing version. These keyboard shortcuts work inside the text area (Focus Mode).\n\n[JAMIE]\nLet's pause on GitHub shortcuts for the Issues pages. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside GitHub shortcuts for the Issues pages: these are the GitHub built-in shortcuts for working with issues. That matters in practice: Enable Focus Mode first (NVDA: NVDA+Space, JAWS: Insert+Z) before using single-key shortcuts.\n\n[JAMIE]\nThat is the part I would want someone to say out loud while they work.\n\n[ALEX]\nExactly. A learner should always know what they are trying to prove before they take the next action.\n\n[PAUSE]\n\n[ALEX]\nThis is where confidence starts to build. Anchor this part on On the Issues list page. Shortcut note: For G I, press G, release it, then press I (two sequential key presses, not simultaneous). The durable skill is not memorizing one screen. It is knowing how to find your footing when the screen changes.\n\n[JAMIE]\nLet's pause on On an open issue. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: r to quote is a power move: Select any text in a comment while in Browse Mode (Shift+Arrow to select), then press R. The listener should be able to check this: GitHub puts the quoted text in the comment box as a Markdown blockquote.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is navigate to your comment (3 to jump to comments). Step two is find the \".\" (ellipsis) menu button near your comment. Step three is press Enter on \"Edit\" from that menu. Step four is the comment turns into a text area - switch to Focus Mode. Each step should leave a trace you can name.\n\n[JAMIE]\nBefore we leave On an open issue, what is the practical point?\n\n[ALEX]\nFirst, make your changes. Then, tab to \"Update comment\" button → Enter. If one step does not match what you hear, stop there and re-orient.\n\n[ALEX]\nNow bring the learner back to the room. Learning Cards: Leaving a Comment has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part that makes the next action easier. Press D to jump to the \"Add a comment\" landmark, which places focus near the text area; then Enter Focus Mode to start typing. Use Ctrl+Enter to submit your comment directly from inside the text area -- this avoids having to Tab through the formatting toolbar to find the Comment button. To quote someone's text in your reply, select the text in Browse Mode (Shift+Arrow), then press R; GitHub inserts it as a blockquote in the comment box automatically. The comment text area expands as you type and is full-width at high zoom, making it easy to target; use Ctrl+Enter to submit without hunting for the Comment button. Use the Preview tab next to Write to check your Markdown formatting in rendered form before posting; bold, code blocks, and links are much easier to proofread there. Keyboard formatting shortcuts (Ctrl+B for bold, Ctrl+E for inline code) work inside the text area and save time over clicking small toolbar icons.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Navigating to New Issue. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, Navigating to New Issue is still useful because from the Issues list page, click the green New issue button in the top-right of the issue list. For someone navigating by keyboard or screen reader, this detail matters: If the repository has templates, a template picker page appears - click Get started next to the template that fits your needs, or click Open a blank issue to skip templates.\n\n[ALEX]\nThis is where the lesson becomes something you can check. At 200%+ zoom, the button may move below the search bar or wrap to its own line. It remains a prominent green button. If the repository has issue templates, a template picker page appears with each template as a card. Template descriptions may truncate at high zoom. Hover over a truncated description for the full text. The Get started button next to each template is small but uses standard link styling. Press Tab to move between templates and their Get started buttons. Open a blank issue link appears at the bottom of the template list. At high zoom, scroll down to find it.\n\n[ALEX]\nStart here: Press K to navigate links and find the \"New issue\" button/link. Then: Press Enter. Next: If a template picker appears: press 3 to navigate template names, read the description below each, then press Enter on \"Get started\" for the right template - or find \"Open a blank issue.\" link if no template fits. Last: Quick Nav B or VO+U → Buttons to find the \"New issue\" button. That is the rhythm: orient, act, verify, continue.\n\n[JAMIE]\nBefore we leave Navigating to New Issue, what is the practical point?\n\n[ALEX]\nWalk it in order: VO+Space to activate it; and If a template picker appears: Quick Nav H or VO+Cmd+H to navigate template names, then VO+Space on \"Get started\" for the right template - or Quick Nav K to find the \"Open a blank issue\" link. That small check between steps is what makes the workflow reliable.\n\n[ALEX]\nThat matters because of the next idea. Put Filling Out the Issue Form into plain language. The issue form has these fields (order may vary depending on the template). The interface gets easier when it becomes a set of named places instead of a wall of controls.\n\n[JAMIE]\nSo this is less about memorizing and more about noticing.\n\n[ALEX]\nRight. Once the learner can name the move, the interface becomes much less intimidating.\n\n[JAMIE]\nLet's pause on Title field. What should a learner take away from it?\n\n[ALEX]\nTitle field has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThink of this as 4 checks: Find the Title input field (F or by landmark); Focus Mode → type a clear, specific title; Good title: \"Screen reader announces wrong element count on Issues list with 50+ items\"; and Bad title: \"Bug with screen reader\". The sequence works because every action has a confirmation.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Description / Body field. What should a learner take away from it?\n\n[ALEX]\nDescription / Body field has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is tab to the body text area. Step two is focus Mode → type using the Markdown template provided. Step three is if no template, use this structure. Keep it that plain: know where you are, make the move, check the result.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like What happened; Describe what you observed.; What I expected; Describe what should have happened.; How to reproduce; 1. Step one; 2. Step two; 3. Step three; Environment; - Screen reader: [NVDA 2025.3.3 / JAWS 2026 / VoiceOver macOS Sonoma]; - Browser: [Chrome. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nLet's pause on Assigning labels from the sidebar. What should a learner take away from it?\n\n[ALEX]\nAssigning labels from the sidebar: See also: Chapter 09: Labels, Milestones, and Projects covers the full label and milestone system. The next useful detail is concrete: While the form is open, the sidebar has dropdowns for Labels, Assignees, and Milestone.\n\n[ALEX]\nFirst, tab away from the text area (or press Escape to leave Focus Mode). Then, navigate to the sidebar - press H to find \"Labels\" heading. After that, press Enter on the Labels gear/button. Finally, dropdown opens → ↑/↓ to navigate labels. Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave Assigning labels from the sidebar, what is the practical point?\n\n[ALEX]\nStart here: Enter to select/deselect. Then: Escape to close (selections save automatically). Next: VO+Shift+Up to stop interacting with the text area. Last: VO+U → Headings to find the \"Labels\" heading in the sidebar. The point is not speed; the point is never losing your place.\n\n[ALEX]\nA solid project habit is to treat metadata as decision support. Labels, status, assignees, and notifications tell you what kind of attention the work needs.\n\n[JAMIE]\nLet's pause on Submitting the issue. What should a learner take away from it?\n\n[ALEX]\nHere is the learner-facing version. GitHub CLI (gh) alternative - filing a new issue. Put another way, create an issue from your terminal. A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[ALEX]\nStart here: Tab to \"Submit new issue\" button. Then: Press Enter. The point is not speed; the point is never losing your place.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Interactive: prompts for title, body, labels, and assignees; gh issue create; Inline: provide everything on the command line; gh issue create --title \"Screen reader announces wrong count on Issues list\" \\; --body \" What happened\\n\\nThe count says 14 but only. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Learning Cards: Filing a New Issue. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Filing a New Issue has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. After pressing \"New issue,\" if a template picker appears, press 3 to jump between template names; each has a \"Get started\" link next to it. In the title field, type at least 12 characters for a meaningful title; press Tab to move to the body field. Press Ctrl+Enter from inside the body text area to submit the issue without needing to find the Submit button. The green \"New issue\" button is in the top-right of the Issues list page; at 200%+ zoom it may wrap below the search bar. Template cards (if the repo uses them) show truncated descriptions at high zoom; hover over them for the full text. The sidebar dropdowns for Labels, Assignees, and Milestone are gear icons that may be small at high zoom; they open searchable dropdown panels.\n\n[JAMIE]\nLet's pause on Tool Cards: File a New Issue. What should a learner take away from it?\n\n[ALEX]\nAnchor this part on Tool Cards: File a New Issue. github.dev (web editor): Not available -- issues are managed through the repository's Issues tab, not the code editor. This is the part to say slowly: VS Code Desktop (GitHub Pull Requests extension).\n\n[ALEX]\nThink of this as 4 checks: Navigate to the repository's Issues tab (or press G then I); Click New issue, choose a template or blank issue; Fill in the title and description, then click Submit new issue; and Open the GitHub panel in the sidebar. If one step does not match what you hear, stop there and re-orient.\n\n[JAMIE]\nBefore we leave Tool Cards: File a New Issue, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is under Issues, click the + icon to create a new issue. Step two is fill in the title and body, then click Create. That is the rhythm: orient, act, verify, continue.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like gh issue create --title \"Your title\" --body \"Description here\"; Or interactively:; gh issue create. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nLet's pause on Cross-Referencing Issues. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: linking issues and PRs to each other creates a trail of context that helps everyone understand the project's history.\n\n[PAUSE]\n\n[ALEX]\nKeep the thread going. Do not treat Closing keywords in PR descriptions or issue comments as decoration. When you type these phrases in a PR description or comment (followed by an issue number), GitHub creates a connection. The workshop is closer to rehearsal than lecture. You hear the move, try the move, and then check what changed.\n\n[JAMIE]\nLet's pause on Mentioning another issue in a comment. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, Mentioning another issue in a comment is still useful because simply type followed by a number anywhere in a comment body. For someone navigating by keyboard or screen reader, this detail matters: GitHub autocompletes with a dropdown of matching issues and PRs.\n\n[ALEX]\nThis is the part worth saying out loud. Put Cross-repo references into plain language. owner/repo 42 - references issue 42 in a different repository.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Learning Cards: Cross-Referencing Issues. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Cross-Referencing Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Type in any comment body to trigger GitHub's autocomplete dropdown; press Down Arrow to browse matching issues and Enter to insert the reference link. Use Closes 42 (not just 42) in PR descriptions so GitHub automatically closes the issue on merge; your screen reader will confirm the link is created in the PR timeline. Cross-references appear as timeline events on the linked issue; navigate with H to find \"mentioned this issue\" entries to trace the conversation history. Cross-reference links ( 42) render as colored, clickable links in both issue bodies and PR descriptions; at high zoom they remain inline with surrounding text. The autocomplete dropdown triggered by may overlap content at high magnification; type additional digits to narrow results and reduce dropdown size. Back-links appear automatically on the referenced issue's timeline, so you can verify the connection was created by visiting either side.\n\n[ALEX]\nKeep the teaching thread moving. This part earns its place because sub-issues (released 2025) let you nest issues inside a parent issue to break large work into tracked pieces. That gives the learner a foothold: a \"parent\" issue contains a list of child issues; each child is a full issue with its own discussion, labels, and assignees. That is the difference between following directions and owning the workflow.\n\n[JAMIE]\nCan you translate that into plain choices?\n\n[ALEX]\nWhen to Use Sub-Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nUse the comparison to make a decision, not to recite a table. The main contrasts are: Large feature broken down means Parent: \"Redesign navigation\"; Children: \"Keyboard nav,\" \"Screen reader nav,\" \"Mobile nav\". Epic tracking means Parent: \"WCAG 2.1 AA compliance\"; Children: one issue per failing criterion. Release milestone means Parent: \"v2.0 release\"; Children: every required PR/fix.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Here is the learner-facing version. The sub-issues section is announced as a region. Put another way, after linking, the child issue appears as a list item with a checkbox showing its open/closed state.\n\n[JAMIE]\nLet's pause on Reading Sub-Issues on a Parent Issue. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside Reading Sub-Issues on a Parent Issue: progress indicator: The parent issue shows a completion bar (e.g., \"3 of 7 completed\") based on how many child issues are closed. That matters in practice: Screen readers announce this as a progress region.\n\n[ALEX]\nKeep the teaching thread moving. Anchor this part on Viewing a Child Issue's Parent. Every child issue shows a \"Parent issue\" link near the top of the page (above the description). This is the part to say slowly: Navigate with H or links (K) to find it. The durable skill is not memorizing one screen. It is knowing how to find your footing when the screen changes.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Sub-Issues vs. Task Lists. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: if you are working on a feature that requires multiple PRs or involves several team members, ask the maintainer to create a parent issue. The listener should be able to check this: You can then claim individual child issues without one person owning the whole feature.\n\n[ALEX]\nKeep the teaching thread moving. Learning Cards: Sub-Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. The sub-issues section is announced as a region; press H to navigate to the \"Sub-issues\" heading, then arrow down through the list where each child announces its checkbox state, title, and open/closed badge. The parent issue shows a progress indicator (\"3 of 7 completed\") announced as a progress region; listen for this after the sub-issues heading to gauge overall status. Every child issue includes a \"Parent issue\" link near the top of its page; navigate with K (links) to find it and jump back to the parent quickly. The completion progress bar on the parent issue uses color to show progress; in high-contrast mode, completed vs. remaining segments use distinct system colors. At high zoom, the \"Add sub-issue\" button may wrap below the sub-issues list; Tab past the last child item to reach it. Each child issue's open/closed badge uses both color and text (\"Open\" or \"Closed\"), so status is readable without relying on color alone.\n\n[JAMIE]\nLet's pause on Closing an issue. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, Closing an issue is still useful because scroll to the bottom of the issue page. For someone navigating by keyboard or screen reader, this detail matters: Click the Close issue button next to the comment box.\n\n[ALEX]\nStart here: Keyboard shortcut (fastest): Navigate to the comment text area (D → \"Add a comment\" landmark), switch to Focus Mode, then press Ctrl+Shift+Enter to close the issue. Then: Button approach: Tab to the \"Close issue\" button (at the bottom of the page, near the comment box) and press Enter. Next: Optionally leave a closing comment first. Last: Keyboard shortcut (fastest): VO+U → Landmarks → \"Add a comment\", interact with the text area (VO+Shift+Down), then press Cmd+Shift+Return to close the issue. Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave Closing an issue, what is the practical point?\n\n[ALEX]\nWalk it in order: Button approach: Quick Nav B or Tab to find the \"Close issue\" button, then VO+Space. The point is not speed; the point is never losing your place.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Close an issue; gh issue close 42; Close with a reason; gh issue close 42 --reason \"completed\"; gh issue close 42 --reason \"not planned\"; Close with a comment; gh issue close 42 --comment \"Fixed in PR 45.\"; Reopen a closed issue; gh issue reopen 42. Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Put Reopening a closed issue into plain language. If an issue is Closed, the \"Close issue\" button becomes \"Reopen issue\" - navigate and activate to reopen. The interface gets easier when it becomes a set of named places instead of a wall of controls.\n\n[JAMIE]\nLet's pause on Assigning an issue. What should a learner take away from it?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. GitHub CLI (gh) alternative - assigning and labeling. That is the difference between guessing and knowing: Manage assignments and labels from your terminal.\n\n[ALEX]\nThink of this as 4 checks: Navigate to \"Assignees\" heading (3 or H); Activate the gear/plus button; Type a username in the search field; and Select from the dropdown. Each step should leave a trace you can name.\n\n[ALEX]\nTreat examples as spoken recipes, not decorations. You may hear something like Assign yourself; gh issue edit 42 --add-assignee @me; Add labels; gh issue edit 42 --add-label \"accessibility,in progress\"; Remove a label; gh issue edit 42 --remove-label \"needs triage\"; Set a milestone; gh issue edit 42 --milestone \"Hackathon Day 1\". Read the command, understand what it changes, then run it only when the repository state matches the lesson.\n\n[JAMIE]\nLet's pause on Changing labels. What should a learner take away from it?\n\n[ALEX]\nChanging labels has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is navigate to \"Labels\" heading. Step two is activate the gear button. Step three is select/deselect labels from the dropdown. Step four is press Escape to save. If one step does not match what you hear, stop there and re-orient.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Transferring or deleting an issue. What should a learner take away from it?\n\n[ALEX]\nTransferring or deleting an issue: Available from the \".\" (ellipsis) button at the top of the issue - navigate buttons with B to find it.\n\n[ALEX]\nKeep the teaching thread moving. Learning Cards: Managing Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Close an issue instantly with Ctrl+Shift+Enter from the comment text area (Focus Mode) -- no need to Tab to the Close button. The sidebar sections (Assignees, Labels, Milestone) each have their own heading; press H or 3 to jump between them, then activate the gear icon to open each dropdown. Use gh issue edit 42 --add-label \"accessibility\" --add-assignee @me to batch-update labels and assignments from the terminal without navigating sidebar controls. Sidebar controls (Assignees, Labels, Milestone) are narrow at default width; at high zoom they stack vertically and each dropdown opens a searchable overlay that is easier to read. The Close issue button turns green and its label changes to \"Reopen issue\" once closed; in high-contrast mode, both states use distinct system colors. Type in the search field inside each sidebar dropdown (Labels, Assignees) to filter long lists rather than scrolling through all options at high magnification.\n\n[JAMIE]\nLet's pause on The \"good first issue\" Label - Your Entry Point. What should a learner take away from it?\n\n[ALEX]\nThis is the move inside The \"good first issue\" Label - Your Entry Point: when looking for your first open source contribution. That matters in practice: Remember: It's respectful to ask before starting.\n\n[ALEX]\nWalk it in order: Navigate to any project's Issues tab; Filter by label: type is:open label:\"good first issue\" in the search; Read through issues until you find one in your area of interest; and Comment on the issue: \"Hi, I'd like to work on this. Can I be assigned?\". The sequence works because every action has a confirmation.\n\n[JAMIE]\nBefore we leave The \"good first issue\" Label - Your Entry Point, what is the practical point?\n\n[ALEX]\nThink of this as 1 checks: Wait for a maintainer to respond and assign you before starting work. Keep it that plain: know where you are, make the move, check the result.\n\n[PAUSE]\n\n[ALEX]\nKeep the teaching thread moving. Learning Cards: The \"good first issue\" Label has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Use the filter query is:open label:\"good first issue\" in the search bar to jump directly to beginner-friendly issues; gh issue list --label \"good first issue\" does the same in the terminal. Before claiming an issue, read existing comments to check whether someone else has already been assigned; listen for \"assigned to\" in the sidebar metadata. When you comment to claim an issue, include a sentence about your approach so the maintainer can give early feedback before you start coding. The \"good first issue\" label renders with a distinct background color (typically light purple or teal); in high-contrast mode it uses system highlight colors with readable text. Filter results may include issues with multiple labels stacked together; at high zoom, labels wrap to a second line but remain readable. Bookmark the filtered URL (/issues?q=is:open+label:\"good first issue\") in your browser for one-click access to beginner issues across your favorite repositories.\n\n[JAMIE]\nLet's pause on Accessibility-Specific Issue Writing Tips. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: when filing accessibility bugs, these details help maintainers reproduce and fix the problem.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is screen reader and version - \"NVDA 2025.3.3\" not just \"screen reader\". Step two is oS and version - \"Windows 11 22H2\". Step three is browser and version - \"Chrome 124.0.6367.82\". Step four is GitHub interface - \"Modern experience (default since Jan 2026)\" or \"Classic experience (opted out)\". Pause after each step and listen for the confirmation before moving on.\n\n[JAMIE]\nBefore we leave Accessibility-Specific Issue Writing Tips, what is the practical point?\n\n[ALEX]\nFirst, what was announced - quote the exact text your screen reader spoke. Then, what should have been announced - describe the expected behavior. After that, aRIA issue if known - e.g., \"The button has no accessible name\". Finally, steps to reproduce - numbered, step-by-step. The point is not speed; the point is never losing your place.\n\n[ALEX]\nKeep the teaching thread moving. Example of a well-filed accessibility issue has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Learning Cards: Accessibility-Specific Issue Writing. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Accessibility-Specific Issue Writing has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Always quote the exact text your screen reader announced in the issue body; wrap it in a fenced code block so readers know it is literal output, not your description. Include your screen reader name and version (e.g., \"NVDA 2025.3.3\") plus browser and OS; this lets maintainers reproduce with the same toolchain. Test with a second screen reader or browser if possible and note the results -- \"Also fails in JAWS 2026 with Chrome; works in VoiceOver with Safari\" dramatically narrows the debugging scope. When filing zoom or contrast bugs, state your exact zoom level and whether you use Windows High Contrast, macOS Increase Contrast, or a browser extension. Screenshots are powerful evidence; annotate them (circle the problem area, add a text callout) and always include alt text describing what the screenshot shows. Note whether the issue occurs only at certain zoom levels or viewport widths; a bug at 400% that disappears at 200% points to a CSS breakpoint problem.\n\n[ALEX]\nKeep the teaching thread moving. Put Writing Effective Issues into plain language. See also: Appendix N: Advanced Search covers search qualifiers to find existing issues before filing a new one. The useful version is: A well-written issue saves everyone time -- the maintainer who reads it, the contributor who fixes it, and the future searcher who finds it six months later.\n\n[JAMIE]\nLet's pause on Bug Report Structure. What should a learner take away from it?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. A strong bug report answers five questions. That is the difference between guessing and knowing: Use this template every time you report something broken.\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Feature Request Structure. What should a learner take away from it?\n\n[ALEX]\nThis part earns its place because feature requests work best when they focus on the problem before jumping to the solution. That gives the learner a foothold: a feature request that starts with \"I want a dark mode toggle\" is weaker than one that starts with \"Low-vision users report eyestrain after 20 minutes because the current theme has insufficient contrast.\" The second version gives maintainers something to. That is the difference between following directions and owning the workflow.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is problem statement -- Describe the pain point. What are you trying to do, and why is it hard or impossible right now? Step two is proposed solution -- Your best idea for fixing the problem. Be specific enough to discuss, but hold it loosely. Step three is alternatives considered -- Other approaches you thought about and why they fell short. This shows you have done your homework. Step four is who benefits -- Name the audience. \"Screen reader users navigating large repositories\" is more compelling than \"everyone.\". That small check between steps is what makes the workflow reliable.\n\n[JAMIE]\nLet's pause on General Issue Writing Principles. What should a learner take away from it?\n\n[ALEX]\nGeneral Issue Writing Principles: These rules apply to every issue -- bugs, features, questions, and everything in between. The next useful detail is concrete: If you discovered two bugs during the same session, file two separate issues.\n\n[ALEX]\nKeep the teaching thread moving. Here is the learner-facing version. I tried clicking and nothing happened. Put another way, the maintainer has to ask: What doesn't work?\n\n[PAUSE]\n\n[JAMIE]\nLet's pause on Learning Cards: Writing Effective Issues. What should a learner take away from it?\n\n[ALEX]\nLearning Cards: Writing Effective Issues has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nHere is the part to remember. Use fenced code blocks (triple backticks) when pasting error messages or screen reader output; your screen reader announces \"code block\" so listeners know the text is literal, not description. When writing \"Steps to Reproduce,\" type each step as a numbered Markdown list item (1., 2., etc.) so screen readers announce \"list with N items\". Type in the comment body to trigger issue autocomplete; press Down Arrow to navigate matching issues and Enter to insert a cross-reference link. Use the Preview tab (next to Write) to check your Markdown rendering before submitting; headings, bold text, and code blocks are much easier to proofread in rendered form. Screenshots with alt text are valuable evidence; add them with the image button in the formatting toolbar or drag-and-drop into the body field. Keep paragraphs short (3-4 sentences max) so the issue is scannable at high zoom without excessive scrolling.\n\n[JAMIE]\nLet's pause on Try It: File Your First Issue. What should a learner take away from it?\n\n[ALEX]\nAnchor this part on Try It: File Your First Issue. Time: 3 minutes What you need: Browser, signed in to GitHub. This is the part to say slowly: Go to the Learning Room repository and file a real issue. The durable skill is not memorizing one screen. It is knowing how to find your footing when the screen changes.\n\n[ALEX]\nThink of this as 4 checks: Navigate to the Issues tab (press G then I in Focus Mode); Find and activate the \"New issue\" button (K to links, or Tab to it); In the title field, type: \"Introduce myself - [Your Name]\"; and In the description, write 2-3 sentences: who you are, what screen reader you use, and one thing you're hoping to learn today. The point is not speed; the point is never losing your place.\n\n[JAMIE]\nBefore we leave Try It: File Your First Issue, what is the practical point?\n\n[ALEX]\nThe path is straightforward once it is named. Step one is press Ctrl+Enter to submit (or Tab to the Submit button and press Enter). Each step should leave a trace you can name.\n\n[JAMIE]\nLet's pause on Learning Cards: Filing Your First Issue. What should a learner take away from it?\n\n[ALEX]\nThe reason this matters is simple: day 2 Amplifier - Accessibility Agents: @issue-tracker File, read, comment on, and triage real issues manually before using any agent. The listener should be able to check this: If you have not done the triage work yourself - reading descriptions, assigning labels, identifying duplicates - you cannot evaluate whether an agent's priority scoring is correct.\n\n[ALEX]\nHere is the part to remember. After pressing Ctrl+Enter to submit, listen for the page reload; GitHub navigates to your new issue page where the title is the first heading -- press 1 to confirm it matches what you typed. Navigate the issue list with 3 (heading level 3) to jump between issue titles; this is faster than arrowing through every element on the page. If the template picker appears, use Tab and Enter to select \"Open a blank issue\"; template names are announced as link text. The \"New issue\" button is prominent and green on the Issues list page; at high zoom it remains visible near the top of the page and does not collapse into a menu.\n\n[PAUSE]\n\n[JAMIE]\nWhat should people carry with them after this?\n\n[ALEX]\nCarry the map. Know what page or tool you are in, know which action you are taking, and know what confirmation should follow. If the confirmation is missing, pause. That pause is not wasted time; it is professional judgment.\n\n[JAMIE]\nThat is a better way to say it than just follow the steps.\n\n[ALEX]\nRight. Steps matter, but understanding wins. That is episode 5. Next in the series is episode 6, where we keep building the same contributor muscles.\n", + "chapterPlanText": "{\n \"version\": 1,\n \"slug\": \"ep05-working-with-issues\",\n \"chapters\": [\n {\n \"title\": \"Opening\",\n \"startSegmentIndex\": 0\n },\n {\n \"title\": \"Issues as Collaboration\",\n \"startSegmentIndex\": 7\n },\n {\n \"title\": \"Challenge Roadmap\",\n \"startSegmentIndex\": 9\n },\n {\n \"title\": \"Create Your First Issue\",\n \"startSegmentIndex\": 17\n },\n {\n \"title\": \"Comment and @Mention\",\n \"startSegmentIndex\": 23\n },\n {\n \"title\": \"Add a Sub-Issue\",\n \"startSegmentIndex\": 29\n },\n {\n \"title\": \"What Success Looks Like\",\n \"startSegmentIndex\": 38\n },\n {\n \"title\": \"Recovery Moves\",\n \"startSegmentIndex\": 42\n },\n {\n \"title\": \"Why Issues Matter\",\n \"startSegmentIndex\": 48\n },\n {\n \"title\": \"The Learning Pattern\",\n \"startSegmentIndex\": 49\n },\n {\n \"title\": \"CLI Alternative\",\n \"startSegmentIndex\": 56\n },\n {\n \"title\": \"What Issues Are For\",\n \"startSegmentIndex\": 61\n },\n {\n \"title\": \"Learning Cards: Navigating to the Issues List\",\n \"startSegmentIndex\": 71\n },\n {\n \"title\": \"Learning Cards: The Issues List Page\",\n \"startSegmentIndex\": 86\n },\n {\n \"title\": \"Search and Filter Issues\",\n \"startSegmentIndex\": 90\n },\n {\n \"title\": \"Learning Cards: Filtering and Searching Issues\",\n \"startSegmentIndex\": 106\n },\n {\n \"title\": \"Learning Cards: Reading an Issue\",\n \"startSegmentIndex\": 120\n },\n {\n \"title\": \"Step-by-step\",\n \"startSegmentIndex\": 123\n },\n {\n \"title\": \"On the Issues list page\",\n \"startSegmentIndex\": 135\n },\n {\n \"title\": \"Learning Cards: Leaving a Comment\",\n \"startSegmentIndex\": 141\n },\n {\n \"title\": \"Learning Cards: Filing a New Issue\",\n \"startSegmentIndex\": 171\n },\n {\n \"title\": \"Link Issues Together\",\n \"startSegmentIndex\": 180\n },\n {\n \"title\": \"Learning Cards: Cross-Referencing Issues\",\n \"startSegmentIndex\": 188\n },\n {\n \"title\": \"Sub-Issues - Parent and Child Relationships\",\n \"startSegmentIndex\": 191\n },\n {\n \"title\": \"The \\\"good first issue\\\" Label - Your Entry Point\",\n \"startSegmentIndex\": 225\n },\n {\n \"title\": \"Accessibility-Specific Issue Writing Tips\",\n \"startSegmentIndex\": 233\n },\n {\n \"title\": \"Writing Effective Issues\",\n \"startSegmentIndex\": 243\n },\n {\n \"title\": \"Try It: File Your First Issue\",\n \"startSegmentIndex\": 257\n },\n {\n \"title\": \"Closing Takeaways\",\n \"startSegmentIndex\": 266\n }\n ]\n}\n", + "sourceFiles": [ + { + "path": "S:\\code\\git-going-with-github\\docs\\05-working-with-issues.md", + "headings": [ + { + "level": 2, + "title": "Filing, Managing, and Participating in GitHub Issues" + }, + { + "level": 2, + "title": "Workshop Recommendation (Chapter 5 / Challenges 2-3)" + }, + { + "level": 3, + "title": "Chapter 5 Challenge Set" + }, + { + "level": 3, + "title": "Challenge 2 Step-by-Step: Create Your First Issue" + }, + { + "level": 3, + "title": "Challenge 3 Step-by-Step: Comment and @Mention" + }, + { + "level": 3, + "title": "Optional Extension Step-by-Step: Add a Sub-Issue" + }, + { + "level": 3, + "title": "Completing Chapter 5: Submit Your Evidence" + }, + { + "level": 3, + "title": "Expected Outcomes" + }, + { + "level": 3, + "title": "If You Get Stuck" + }, + { + "level": 3, + "title": "Learning Moment" + }, + { + "level": 3, + "title": "Learning Pattern Used in This Chapter" + }, + { + "level": 3, + "title": "About Learning Cards in This Chapter" + }, + { + "level": 2, + "title": "Local Git Alternative: Working from Your Clone" + }, + { + "level": 2, + "title": "What Is a GitHub Issue?" + }, + { + "level": 2, + "title": "Navigating to the Issues List" + }, + { + "level": 3, + "title": "From a repository page" + }, + { + "level": 3, + "title": "Direct URL" + }, + { + "level": 3, + "title": "Learning Cards: Navigating to the Issues List" + }, + { + "level": 2, + "title": "The Issues List Page" + }, + { + "level": 3, + "title": "Page structure" + }, + { + "level": 3, + "title": "How to read the issue list" + }, + { + "level": 3, + "title": "What is announced per issue" + }, + { + "level": 3, + "title": "Learning Cards: The Issues List Page" + }, + { + "level": 2, + "title": "Filtering and Searching Issues" + }, + { + "level": 3, + "title": "Using the search/filter bar" + }, + { + "level": 4, + "title": "Useful filter queries" + }, + { + "level": 3, + "title": "Using the filter buttons" + }, + { + "level": 3, + "title": "Open vs Closed filter" + }, + { + "level": 3, + "title": "Learning Cards: Filtering and Searching Issues" + }, + { + "level": 2, + "title": "Reading an Issue" + }, + { + "level": 3, + "title": "Landing on an issue page" + }, + { + "level": 3, + "title": "Quick navigation" + }, + { + "level": 3, + "title": "Reading the issue description" + }, + { + "level": 3, + "title": "Reading comments and activity" + }, + { + "level": 3, + "title": "Learning Cards: Reading an Issue" + }, + { + "level": 2, + "title": "Leaving a Comment" + }, + { + "level": 3, + "title": "Step-by-step" + }, + { + "level": 3, + "title": "Markdown formatting while typing" + }, + { + "level": 3, + "title": "GitHub shortcuts for the Issues pages" + }, + { + "level": 4, + "title": "On the Issues list page" + }, + { + "level": 4, + "title": "On an open issue" + }, + { + "level": 3, + "title": "Learning Cards: Leaving a Comment" + }, + { + "level": 2, + "title": "Filing a New Issue" + }, + { + "level": 3, + "title": "Navigating to New Issue" + }, + { + "level": 3, + "title": "Filling Out the Issue Form" + }, + { + "level": 4, + "title": "Title field" + }, + { + "level": 4, + "title": "Description / Body field" + }, + { + "level": 2, + "title": "What happened" + }, + { + "level": 2, + "title": "What I expected" + }, + { + "level": 2, + "title": "How to reproduce" + }, + { + "level": 2, + "title": "Environment" + }, + { + "level": 2, + "title": "Additional context" + }, + { + "level": 3, + "title": "Assigning labels from the sidebar" + }, + { + "level": 3, + "title": "Submitting the issue" + }, + { + "level": 3, + "title": "Learning Cards: Filing a New Issue" + }, + { + "level": 3, + "title": "Tool Cards: File a New Issue" + }, + { + "level": 2, + "title": "Cross-Referencing Issues" + }, + { + "level": 3, + "title": "Closing keywords in PR descriptions or issue comments" + }, + { + "level": 3, + "title": "Mentioning another issue in a comment" + }, + { + "level": 3, + "title": "Cross-repo references" + }, + { + "level": 3, + "title": "Learning Cards: Cross-Referencing Issues" + }, + { + "level": 2, + "title": "Sub-Issues - Parent and Child Relationships" + }, + { + "level": 3, + "title": "When to Use Sub-Issues" + }, + { + "level": 3, + "title": "Creating a Sub-Issue" + }, + { + "level": 3, + "title": "Reading Sub-Issues on a Parent Issue" + }, + { + "level": 3, + "title": "Viewing a Child Issue's Parent" + }, + { + "level": 3, + "title": "Sub-Issues vs. Task Lists" + }, + { + "level": 3, + "title": "Learning Cards: Sub-Issues" + }, + { + "level": 2, + "title": "Managing Issues (for Maintainers and Triagers)" + }, + { + "level": 3, + "title": "Closing an issue" + }, + { + "level": 3, + "title": "Reopening a closed issue" + }, + { + "level": 3, + "title": "Assigning an issue" + }, + { + "level": 3, + "title": "Changing labels" + }, + { + "level": 3, + "title": "Transferring or deleting an issue" + }, + { + "level": 3, + "title": "Learning Cards: Managing Issues" + }, + { + "level": 2, + "title": "The \"good first issue\" Label - Your Entry Point" + }, + { + "level": 3, + "title": "Learning Cards: The \"good first issue\" Label" + }, + { + "level": 2, + "title": "Accessibility-Specific Issue Writing Tips" + }, + { + "level": 3, + "title": "Example of a well-filed accessibility issue" + }, + { + "level": 2, + "title": "What happened" + }, + { + "level": 2, + "title": "What I expected" + }, + { + "level": 2, + "title": "How to reproduce" + }, + { + "level": 2, + "title": "Environment" + }, + { + "level": 2, + "title": "Additional context" + }, + { + "level": 3, + "title": "Learning Cards: Accessibility-Specific Issue Writing" + }, + { + "level": 2, + "title": "Writing Effective Issues" + }, + { + "level": 3, + "title": "Bug Report Structure" + }, + { + "level": 3, + "title": "Feature Request Structure" + }, + { + "level": 3, + "title": "General Issue Writing Principles" + }, + { + "level": 3, + "title": "Before and After: A Vague Issue vs. a Clear Issue" + }, + { + "level": 3, + "title": "Learning Cards: Writing Effective Issues" + }, + { + "level": 2, + "title": "Try It: File Your First Issue" + }, + { + "level": 3, + "title": "Learning Cards: Filing Your First Issue" + } + ], + "content": "# Working with Issues\r\n>\r\n> **Listen to Episode 5:** [Working with Issues](../admin/PODCASTS.md) - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.\r\n\r\n> **Related appendices:** [Appendix N: Advanced Search](appendix-n-advanced-search.md) | [Appendix V: GitHub Mobile](appendix-v-github-mobile.md) | [Appendix B: Screen Reader Cheat Sheet](appendix-b-screen-reader-cheatsheet.md)\r\n> **Authoritative sources:** [GitHub Docs: About issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues) | [GitHub Accessibility Guide: Issues](https://accessibility.github.com/documentation/guide/issues/)\r\n\r\n\r\n## Filing, Managing, and Participating in GitHub Issues\r\n\r\n> Issues are where open source collaboration begins. This guide covers everything from finding the right issue to file a perfect bug report - all with your keyboard and screen reader.\r\n>\r\n> **Official GitHub Accessibility Guide:** GitHub publishes an NVDA-focused guide for working with issues using a screen reader at [Using GitHub Issues with a Screen Reader](https://accessibility.github.com/documentation/guide/issues/). This chapter covers the same material with additional perspectives (VoiceOver, low vision, CLI) and workshop-specific challenges. Use the official guide as a companion reference.\r\n>\r\n> **Screen reader note - New Issues Experience:** This guide uses GitHub's improved Issues experience, which provides better ARIA landmark structure and live-region announcements for screen readers. This feature may already be active for your account - it has been broadly rolled out and may no longer appear as a Feature Preview toggle at all.\r\n>\r\n> **To verify:** Activate the **User Menu** button (top-right of any GitHub page) → activate **\"Feature preview\"** → scan the list for **\"New Issues Experience\"**:\r\n>\r\n> - If listed and the toggle announces **\"Pressed\"** (or **\"Disable\"**) - already enabled, no action needed\r\n> - If listed but **not Pressed** (or **\"Enable\"**) - activate the toggle to enable it\r\n> - If not listed at all - the feature has graduated to the standard interface; it is active automatically\r\n>\r\n> Full step-by-step instructions with per-screen-reader commands are in [Pre-Workshop Setup, Step 4](00-pre-workshop-setup.md#step-4---check-github-feature-preview-settings).\r\n>\r\n> **Browse vs Focus Mode (NVDA):** Toggle between modes with `NVDA+Space` (NVDA key = `Insert` or `Caps Lock`). Use **Browse Mode** (the default) for reading lists, headings, and issue content. Switch to **Focus Mode** when typing in text fields and search boxes. Use `NVDA+F7` at any time to open a list of all headings, links, form fields, buttons, and landmarks on the page - this is your orientation tool.\r\n\r\n\r\n## Workshop Recommendation (Chapter 5 / Challenges 2-3)\r\n\r\nChapter 5 is the first **issue-based challenge chapter** with short, confidence-building tasks. It supports Challenge 2 (File Your First Issue) and Challenge 3 (Join the Conversation).\r\n\r\n- **Challenge count:** 2 core challenges plus one optional extension\r\n- **Time per challenge:** under 10 minutes\r\n- **Evidence:** issue comments and issue metadata\r\n- **Pattern:** claim -> act -> confirm\r\n\r\n### Chapter 5 Challenge Set\r\n\r\n1. **Create your first issue** - file a new issue with a clear title and description.\r\n2. **Comment and @mention** - leave a comment on a classmate's issue and tag them with an @mention.\r\n3. **Optional extension: Add a sub-issue** - break a larger issue into smaller, trackable pieces if your repository has sub-issues enabled.\r\n\r\n> **Branch guidance for Chapter 5:** Chapter 5 focuses on issue skills. You do NOT need to create a branch or edit any files for these challenges. All your work happens in GitHub issue threads. File editing and branches start in Chapter 6.\r\n>\r\n> **How completion works:** When you finish the issue challenges, post evidence in your assigned challenge issues with links to the issue you created and the comment you posted. The facilitator reviews your issue activity directly. No pull request is required for Chapter 5.\r\n\r\n### Challenge 2 Step-by-Step: Create Your First Issue\r\n\r\n**Goal:** File a new issue in your Learning Room repository with a specific title and a meaningful description.\r\n\r\n> **Agentic strategy:** Issues are the prompts that wake up AI. A clear issue for a human is also a prompt for an agent. For this challenge, log an issue describing an accessibility problem or chore you wish an AI agent could fix for you.\r\n\r\n**Where you are working:** the Issues tab of your Learning Room repository on GitHub.com.\r\n\r\n1. Open your Learning Room repository in your browser.\r\n2. Navigate to the **Issues** tab (press `G` then `I` to jump there with keyboard shortcuts, or find the \"Issues\" link in the repository navigation).\r\n3. Activate the **New issue** button.\r\n4. If a template picker appears, select **Open a blank issue** (or choose a template if one fits).\r\n5. In the **Title** field, type a clear, specific title (at least 12 characters). Examples:\r\n - \"Agent Request: Add missing contributor background paragraph in welcome.md\"\r\n - \"Keyboard shortcuts table has incorrect NVDA modifier key\"\r\n - \"Setup guide link to accessibility settings is broken\"\r\n6. In the **Body** field, write a meaningful description (at least 80 characters). Include:\r\n - What the problem is or what content is missing.\r\n - Where in the repository the problem exists (file name and section).\r\n - What you think the fix should be.\r\n7. Activate **Submit new issue**.\r\n8. Copy the issue URL or note the issue number (for example, `#150`). You will reference this later.\r\n\r\n**You are done when:** Your new issue appears in the Issues list with your username as the author, a clear title, and a detailed description.\r\n\r\n### Challenge 3 Step-by-Step: Comment and @Mention\r\n\r\n**Goal:** Leave a comment on another student's issue and use an @mention to notify them.\r\n\r\n**Where you are working:** the Issues tab of your Learning Room repository on GitHub.com.\r\n\r\n1. Open the **Issues** tab in your Learning Room repository.\r\n2. Find an issue created by a classmate (look for recent open issues, or use a facilitator-provided peer-simulation issue).\r\n3. Open the issue by activating its title link.\r\n4. Read the issue description to understand what they reported.\r\n5. Scroll to the comment box at the bottom of the issue.\r\n6. Write a helpful comment that **@mentions the issue author by username**. Examples:\r\n - \"@classmate I can confirm this - the link in setup-guide.md goes to a 404 page.\"\r\n - \"@classmate Good catch! I think the correct shortcut is Insert+F7, not Insert+F5.\"\r\n - \"@classmate I'd suggest adding the paragraph right after the 'Who Can Contribute' heading.\"\r\n7. Activate the **Comment** button (or press `Ctrl+Enter`).\r\n\r\n**Why @mentions matter:** When you type `@username`, GitHub sends that person a notification. This is how real open source teams communicate - you signal who needs to see your message. It also bridges into Chapter 10 (Notifications) where you will configure how you receive these alerts.\r\n\r\n**You are done when:** Your comment appears in the thread and includes an @mention (the username renders as a clickable link).\r\n\r\n### Optional Extension Step-by-Step: Add a Sub-Issue\r\n\r\n**Goal:** Break a larger issue into smaller, trackable pieces using GitHub's sub-issue feature.\r\n\r\n**Where you are working:** the issue you created in Challenge 2 (or any open issue you have permission to edit).\r\n\r\n> **What are sub-issues?** Sub-issues let you decompose a big task into smaller steps, each tracked independently. The parent issue shows a progress bar as sub-issues are completed. This is how teams organize real work - a single \"Fix accessibility in welcome.md\" issue might have sub-issues for each specific fix.\r\n\r\n1. Open the issue you created in Challenge 2.\r\n2. Look for the **Sub-issues** section in the issue sidebar (right side on desktop). If you do not see it, look for an **Add sub-issue** button or the **Create sub-issue** option below the issue description.\r\n3. Activate **Add sub-issue** and choose **Create new sub-issue**.\r\n4. Give the sub-issue a clear title that describes one specific piece of the parent issue. For example, if the parent is \"Fix accessibility in welcome.md\":\r\n - Sub-issue: \"Add alt text to welcome banner image\"\r\n - Sub-issue: \"Fix heading hierarchy in Getting Started section\"\r\n5. Add a short description and activate **Create**.\r\n6. The sub-issue now appears nested under the parent issue with a progress indicator.\r\n\r\n**You are done when:** Your parent issue shows at least one sub-issue in the Sub-issues section.\r\n\r\n### Completing Chapter 5: Submit Your Evidence\r\n\r\nWhen you have finished the Chapter 5 issue challenges, go to your **assigned Challenge 2 or Challenge 3 issue** and post a comment with your evidence:\r\n\r\n```text\r\nChapter 5 completed:\r\n- Challenge 2: Created issue #[number]\r\n- Challenge 3: Commented with @mention on issue #[number]\r\n- Optional: Added sub-issue to issue #[number]\r\n```\r\n\r\nReplace `[number]` with the actual issue numbers. Then close your assigned challenge issues. The facilitator will review your issue activity.\r\n\r\n### Expected Outcomes\r\n\r\n- Student can create an issue with a clear title and description.\r\n- Student can communicate in issue threads using @mentions.\r\n- Student can organize work by breaking issues into sub-issues.\r\n\r\n### If You Get Stuck\r\n\r\n1. Can't find a classmate's issue? Filter the Issues tab by `is:open` and look for recent ones.\r\n2. @mention not working? Make sure you type `@` immediately followed by the username with no space.\r\n3. Sub-issue option not visible? Ask a facilitator - the feature may need to be enabled for the repository.\r\n4. Still stuck? Ask a facilitator for a direct issue link.\r\n5. Finished but not sure you did it right? Compare your work against the [Challenge 2 reference solution](solutions/solution-02-first-issue.md) or the [Challenge 3 reference solution](solutions/solution-03-conversation.md).\r\n\r\n### Learning Moment\r\n\r\nIssues are collaborative spaces, not just task lists. An @mention tells someone \"I need your attention here.\" Sub-issues turn vague tasks into clear checklists. Both skills are used daily in real open source projects.\r\n\r\n### Learning Pattern Used in This Chapter\r\n\r\n1. Start with a small, safe action (create an issue).\r\n2. Practice communication in public issue threads (@mention a peer).\r\n3. Organize work into smaller pieces (sub-issues).\r\n4. Leave clear evidence in the issue timeline.\r\n5. Build momentum for file editing and PR work in Chapter 6.\r\n\r\n\r\n### About Learning Cards in This Chapter\r\n\r\nThis chapter provides learning cards: expandable blocks that offer perspective-specific guidance for different ways of working. Not every card appears at every step. Open the ones that match how you work.\r\n\r\nThe following table describes the five learning card types used in this chapter.\r\n\r\n| Card | Who it helps | What it covers |\r\n| --- | --- | --- |\r\n| Visual / mouse | Sighted users navigating with a mouse or trackpad | Click targets, visual cues, layout orientation |\r\n| Low vision | Users with magnification, zoom, or high-contrast themes | Zoom-friendly navigation, finding controls at high magnification, high contrast visibility |\r\n| NVDA / JAWS (Windows) | Screen reader users on Windows | Keystroke sequences, Focus and Browse mode, landmark navigation |\r\n| VoiceOver (macOS) | Screen reader users on macOS | VO key sequences, rotor usage, interaction model |\r\n| CLI (gh) | Terminal users on any platform | GitHub CLI commands for issue management |\r\n\r\n\r\n## Local Git Alternative: Working from Your Clone\r\n\r\n
\r\nIf you cloned the learning-room in Block 0 and prefer working locally\r\n\r\nDuring Block 0 you cloned the Learning Room repository to your computer. If you are comfortable in a terminal, you can use the GitHub CLI (`gh`) from inside that clone for every issue operation in this chapter. This is the same workflow covered in depth in [Chapter 11: Git and Source Control](14-git-in-practice.md).\r\n\r\n**Verify your clone is ready:**\r\n\r\n```bash\r\ncd ~/Documents/learning-room # or wherever you cloned it\r\ngit status # should show \"On branch main\"\r\n```\r\n\r\n**Common issue commands from your local terminal:**\r\n\r\n```bash\r\n# List your assigned challenge issues\r\ngh issue list --assignee @me --label challenge\r\n\r\n# View a specific issue in the terminal\r\ngh issue view 42\r\n\r\n# Leave a comment on an issue\r\ngh issue comment 42 --body \"I'd like to try this!\"\r\n\r\n# Create a new issue interactively\r\ngh issue create\r\n```\r\n\r\nAll of these produce the same result as the web interface. The chapter instructions work identically either way - choose whichever is more comfortable for you.\r\n\r\n
\r\n\r\n\r\n## What Is a GitHub Issue?\r\n\r\nAn issue is a discussion thread attached to a repository. Issues are used for:\r\n\r\n- **Bug reports** - \"This feature doesn't work when using a screen reader\"\r\n- **Feature requests** - \"It would help if the submit button had an accessible label\"\r\n- **Questions** - \"How do I configure X for Y use case?\"\r\n- **Tasks** - \"Update the README with screen reader instructions\"\r\n- **Accessibility reports** - \"The infinite scroll carousel is not keyboard accessible\"\r\n\r\nEvery issue has a **number** (`#42`), a **state** (Open or Closed), a **title**, a **description**, and a **comment thread**. Issues are public by default on public repositories.\r\n\r\n> **Learning Room connection:** In your Learning Room repo, every challenge from `docs/CHALLENGES.md` becomes an issue. For example, Challenge 1 (\"Fix Broken Link\") is filed as an issue pointing to `docs/welcome.md`, describing the broken link and linking to the challenge success criteria. When you open a PR to fix it, you reference the issue with `Closes #XX` to automatically close it on merge.\r\n\r\n\r\n## Navigating to the Issues List\r\n\r\n### From a repository page\r\n\r\n
\r\nVisual / mouse users\r\n\r\nClick the **Issues** tab in the repository navigation bar below the repository name. The tab shows the open issue count (e.g., “Issues · 14”).\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. Press `D` to navigate to the \"Repository navigation\" landmark\r\n2. Press `K` or `Tab` to move through the tab links\r\n3. Find \"Issues\" - it will be announced with the count: \"Issues, 14 open\"\r\n4. Press `Enter` to open the Issues tab\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. `VO+U` → Landmarks → navigate to \"Repository navigation\"\r\n2. `VO+Right` or Quick Nav `K` to move through tab links\r\n3. Find \"Issues\" - VoiceOver announces the count: \"Issues 14\"\r\n4. `VO+Space` to activate the Issues tab\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative\r\n\r\nList open issues directly from your terminal:\r\n\r\n```bash\r\ngh issue list\r\n```\r\n\r\nFilter by label, assignee, or state:\r\n\r\n```bash\r\ngh issue list --label \"good first issue\"\r\ngh issue list --assignee @me\r\ngh issue list --state closed\r\n```\r\n\r\n**Setup:** Install the GitHub CLI from [cli.github.com](https://cli.github.com) and authenticate with `gh auth login`. See [Appendix D](appendix-d-git-authentication.md) for details.\r\n\r\n
\r\n\r\n### Direct URL\r\n\r\nNavigate directly: `https://github.com/[owner]/[repo]/issues`\r\n\r\n### Learning Cards: Navigating to the Issues List\r\n\r\n**Screen reader users:**\r\n- Press `D` to jump to the \"Repository navigation\" landmark, then `K` or `Tab` to find the Issues link -- this is faster than arrowing through the entire page\r\n- The Issues tab announces its open count (\"Issues, 14 open\"), giving you an instant sense of project activity without loading the list\r\n- Use `gh issue list` in the terminal to bypass browser navigation entirely; pipe through `--label` or `--assignee @me` to pre-filter results\r\n\r\n**Low-vision users:**\r\n- The Issues tab count badge may be small at default zoom; at 200%+ the tab text reflows but the count remains visible next to the word \"Issues\"\r\n- Bookmark the direct URL pattern (`github.com/owner/repo/issues`) to skip repository page navigation altogether\r\n- In high-contrast mode, the active tab is indicated with an underline using system highlight color, not just a subtle background change\r\n\r\n**Sighted users:**\r\n- The Issues tab sits in the repository navigation bar directly below the repo name; the open count badge gives a quick pulse check on project health\r\n- Memorize the `G I` keyboard shortcut (press G, release, press I) to jump to Issues from anywhere in the repository without scrolling\r\n- The direct URL pattern works for any repository: swap `[owner]/[repo]` with real values and bookmark your most visited projects\r\n\r\n\r\n## The Issues List Page\r\n\r\n### Page structure\r\n\r\n```\r\n[Search / filter bar] -- controls at the top\r\n[State tabs: Open / Closed] -- filter by status\r\n[Issues list] -- each issue is one list item or heading\r\n[Pagination] -- at the bottom\r\n```\r\n\r\n> **Quick orientation tip:** Press `NVDA+F7` (or `VO+U` on macOS) to open a list of all headings, links, form fields, and buttons on the page. This is often faster than tabbing through many elements and helps you understand the full page structure before diving in. Use `Ctrl+/` (Windows) or `Cmd+/` (Mac) to jump directly to the search field from anywhere on the page.\r\n\r\n### How to read the issue list\r\n\r\n
\r\nVisual / mouse users\r\n\r\nThe issues list shows each issue as a row with its title, labels, number, assignee avatars, and comment count. Closed issues show a purple merged/closed badge. Click any issue title to open it. Use the **Open** and **Closed** toggle links above the list to switch between states.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nEach issue row shows the title, labels (colored badges), number, and comment count. At high magnification:\r\n\r\n- Issue titles are the largest text in each row and remain readable at 200%+ zoom.\r\n- Label badges use colored backgrounds with text inside. In Windows High Contrast mode, labels display with system border colors and readable text rather than colored backgrounds.\r\n- The **Open** and **Closed** toggle links above the list let you switch views. The active toggle is bold or underlined.\r\n- The comment count icon (a speech bubble) may be small at high zoom. It appears to the right of each issue row. Hover to see \"N comments\" tooltip.\r\n- Use `Ctrl+F` (browser Find) to search for a specific issue title if the list is long.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS)\r\n\r\n1. Press `D` to reach the “Search Results List” landmark\r\n2. Press `3` (h3) to navigate by issue titles - each issue title is an h3 link\r\n3. Press `I` to move between list items if you want more detail per item\r\n4. Press `Enter` on a title to open that issue\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver)\r\n\r\n1. `VO+U` → Landmarks → navigate to “Search Results List”\r\n2. `VO+Down` to read through items\r\n3. `H` (with Quick Nav on) or `VO+U` → Headings to jump by issue title\r\n\r\n
\r\n\r\n### What is announced per issue\r\n\r\nWhen you navigate to an issue in the list, your screen reader will announce (in some order):\r\n\r\n- Issue title (as a link)\r\n- Issue number (`#42`)\r\n- Labels (e.g., \"bug, good first issue\")\r\n- Who opened it and when (\"Opened 3 days ago by username\")\r\n- Number of comments (\"5 comments\")\r\n\r\n### Learning Cards: The Issues List Page\r\n\r\n
\r\nScreen reader users\r\n\r\n- Press `D` to jump to the \"Search Results List\" landmark, then press `3` to navigate issue titles (each is an H3 link)\r\n- Press `I` to move between individual list items if you want full detail per issue (number, labels, author, age)\r\n- After applying a filter, the issue list updates silently; press `3` again to re-navigate the updated list from the top\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- Issue titles are the largest text per row and stay readable at 200%+ zoom; labels appear as small colored badges to the right of each title\r\n- The Open/Closed toggle links are near the top of the list; the active state is bold or underlined depending on your theme\r\n- If the comment count icon (speech bubble) is too small at your zoom level, hover over it for a tooltip showing the exact count\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- Each issue row shows: open/closed icon (green circle = open, purple merged icon = closed), title, label badges, PR link icon, comment count, and assignee avatar\r\n- Click the Open/Closed tabs above the list to switch between open and closed issues; the count next to each tab updates as you filter\r\n- Issue labels appear as colored rounded rectangles inline with the title; hover over a label to see its description\r\n\r\n
\r\n\r\n\r\n## Filtering and Searching Issues\r\n\r\nFiltering lets you narrow the list to find the right issue quickly.\r\n\r\n### Using the search/filter bar\r\n\r\n1. Press `F` or `E` to jump to the filter input field (or navigate from the landmark)\r\n2. Switch to Focus Mode (`NVDA+Space` / `Insert+Z`) if not already in it\r\n3. Type your filter or search query\r\n4. Press `Enter` to apply\r\n\r\n#### Useful filter queries\r\n\r\n```text\r\nis:open label:\"good first issue\" ← great for finding your first contribution\r\nis:open label:accessibility ← accessibility-related open issues\r\nis:open assignee:@me ← issues assigned to you\r\nis:open no:assignee ← unassigned issues\r\nis:open author:@me ← issues you filed\r\nmentions:@me ← where you were @mentioned\r\nis:open is:unread ← issues with unread activity\r\n```\r\n\r\n### Using the filter buttons\r\n\r\nAbove the issue list, there is an **actions toolbar** with filter buttons for Labels, Milestones, Assignees, etc.\r\n\r\n> **Screen reader note:** The filter buttons do not indicate the current filter state. After applying a filter, the button text does not change to reflect what is selected. To verify which filters are active, check the search/filter bar text - it updates to show the active filter conditions (for example, `is:open label:accessibility`).\r\n\r\n
\r\nVisual / mouse users\r\n\r\nThe filter bar sits above the issue list. Click **Label**, **Milestone**, or **Assignee** to open a dropdown, select the values you want, then click anywhere outside to close. The issue list updates immediately.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nThe filter bar sits above the issue list. At high magnification:\r\n\r\n- The **Label**, **Milestone**, and **Assignee** buttons may wrap to a second row. Each button opens a dropdown with searchable options.\r\n- Dropdown menus from filter buttons can extend below the visible viewport at high zoom. Scroll within the dropdown to see all options.\r\n- Type in the search field at the top of each dropdown to narrow the list (for example, type \"accessibility\" in the Label dropdown).\r\n- In Windows High Contrast mode, the selected filter values are indicated with a checkmark icon and system highlight color, not just a background color change.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. Press `Tab` from the search bar (or `Shift+Tab` from the issue list) to reach the actions toolbar\r\n2. Press `←/→` to move between toolbar options (Label, Milestone, Assignee, Sort)\r\n3. Press `Enter` to open the selected dropdown\r\n4. Use `↑/↓` to navigate options in the dropdown\r\n5. Press `Enter` or `Space` to select\r\n6. Press `Escape` to close (filter applies immediately)\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. `Tab` forward from the search bar to reach the filter buttons, or use Quick Nav to find them\r\n2. `VO+Left/Right` to move between Label, Milestone, Assignee, Sort buttons\r\n3. `VO+Space` to open the selected dropdown\r\n4. `VO+Down` or arrow keys to navigate the dropdown options\r\n5. `VO+Space` to select/deselect\r\n6. `Escape` to close (filter applies immediately)\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative - filtering\r\n\r\nFilter issues by label, milestone, or assignee without navigating dropdown menus:\r\n\r\n```bash\r\n# Filter by label\r\ngh issue list --label \"accessibility\"\r\n\r\n# Combine filters\r\ngh issue list --label \"good first issue\" --assignee @me\r\n\r\n# Filter by milestone\r\ngh issue list --milestone \"Hackathon Day 1\"\r\n\r\n# Search with keywords\r\ngh issue list --search \"screen reader\"\r\n```\r\n\r\n
\r\n\r\n### Open vs Closed filter\r\n\r\nThe two state links \"Open\" and \"Closed\" appear near the top of the issue list. Press `K` to navigate links until you find them, or look for them as buttons near the search bar.\r\n\r\n### Learning Cards: Filtering and Searching Issues\r\n\r\n**Screen reader users:**\r\n- Switch to Focus Mode (`NVDA+Space`) before typing in the filter bar; switch back to Browse Mode after pressing Enter to read the filtered results\r\n- The filter bar does not announce how many results remain after filtering; press `H` to jump to the issue list heading, then listen for the count in the heading text\r\n- Combine `gh issue list` flags (e.g., `--label \"accessibility\" --assignee @me`) for instant filtered results without navigating dropdown menus\r\n\r\n**Low-vision users:**\r\n- Filter dropdown menus can extend below the viewport at high zoom; scroll within the dropdown or type in the search field at the top of each dropdown to narrow options\r\n- After applying a filter, verify it took effect by checking the search bar text -- it updates to show active conditions like `is:open label:accessibility`\r\n- The `Ctrl+/` (Windows) or `Cmd+/` (Mac) shortcut focuses the search bar instantly, avoiding the need to scroll up to find it\r\n\r\n**Sighted users:**\r\n- Build compound queries in the search bar for precision: `is:open label:\"good first issue\" no:assignee` finds unclaimed starter issues in one step\r\n- The Open/Closed toggle near the top of the list preserves your current filter; click Closed to see resolved issues without losing your label or assignee filter\r\n- Pin your most-used filter as a browser bookmark (the URL updates to reflect the active query) for one-click access\r\n\r\n\r\n## Reading an Issue\r\n\r\n### Landing on an issue page\r\n\r\nWhen you open an issue, the page structure is:\r\n\r\n```text\r\n[Issue title - h1]\r\n[Open/Closed status badge]\r\n[Author, timestamp, comment count]\r\n─────────────────────────────────\r\n[Issue description - Main content] ← the original post\r\n[Labels, Assignees sidebar - h3s]\r\n─────────────────────────────────\r\n[Activity / Timeline] ← comments and events\r\n [First comment - h3]\r\n [Second comment - h3]\r\n ...\r\n─────────────────────────────────\r\n[Add a comment - landmark]\r\n[Comment text area]\r\n[Close issue / Submit button]\r\n```\r\n\r\n### Quick navigation\r\n\r\n| Goal | Key |\r\n| ------ | ----- |\r\n| Hear the issue title | `1` |\r\n| Jump to description | `2` (first h2 is usually \"Description\") |\r\n| Jump to Activity section | `2` → next h2 is \"Activity\" |\r\n| Navigate between comments | `3` (each comment is h3) |\r\n| Jump to comment box | `D` → \"Add a comment\" landmark |\r\n| Navigate labels/assignees | `H` or `3` in the sidebar |\r\n\r\n### Reading the issue description\r\n\r\n1. Press `2` to reach the \"Description\" heading\r\n2. Press `↓` to read the content line by line, OR\r\n3. Use `NVDA+↓` (NVDA say all) to have it read continuously\r\n\r\n> **Browse Mode recommended:** The issue detail page is primarily text-based. Stay in **Browse Mode** (not Focus Mode) for reading - it gives you full heading (`H`), section (`D`), and link (`K`) navigation throughout the page. Only switch to Focus Mode when you need to type in a comment box.\r\n\r\nMarkdown in the description renders as proper HTML: headings become actual headings, bullets become lists, code blocks become `` elements with the text \"code block\" announced.\r\n\r\n
\r\nGitHub CLI (gh) alternative - reading an issue\r\n\r\nView an issue's full content in your terminal:\r\n\r\n```bash\r\n# View issue in terminal (renders Markdown)\r\ngh issue view 42\r\n\r\n# Open the issue in your browser instead\r\ngh issue view 42 --web\r\n\r\n# View just the comments\r\ngh issue view 42 --comments\r\n```\r\n\r\nThe terminal output includes the title, state, labels, assignees, body, and comments. Markdown renders as plain text - headings use `#` symbols, lists use `-`, and code blocks are preserved.\r\n\r\n
\r\n\r\n### Reading comments and activity\r\n\r\nEach comment in the thread is marked as an h3. Navigate between them with `3`.\r\n\r\nEach comment announces:\r\n\r\n- Commenter's username\r\n- Timestamp (\"2 days ago\")\r\n- Body text\r\n- Reactions (if any - announced as a button with an emoji and count)\r\n- A \"Reply\" link\r\n\r\nOther timeline events (label added, PR linked, issue closed) appear between comments in the activity stream. They are typically announced as text paragraphs.\r\n\r\n### Learning Cards: Reading an Issue\r\n\r\n
\r\nScreen reader users\r\n\r\n- Press `1` to hear the issue title, then `2` to reach \"Description\" and \"Activity\" headings, and `3` to jump between individual comments\r\n- Stay in Browse Mode for reading; only switch to Focus Mode (`NVDA+Space`) when you need to type in the comment box\r\n- Press `D` to jump to the \"Add a comment\" landmark at the bottom of the page to skip directly to the reply area\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- The issue title is the largest text on the page, followed by an Open/Closed badge in green or purple\r\n- Comment blocks have a subtle border and a grey header bar showing the author's avatar and timestamp; zoom in on the header to identify commenters\r\n- The sidebar (Labels, Assignees, Milestone) is on the right at desktop width; at high zoom it may move below the main content\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- The issue page has a two-column layout: main content on the left (description, timeline, comment box) and sidebar on the right (labels, assignees, milestone, linked PRs)\r\n- Each comment shows the author's avatar in the left margin, with a header bar containing their username and a relative timestamp\r\n- Timeline events (label changes, assignments, cross-references) appear as small lines between comments with icons indicating the event type\r\n\r\n
\r\n\r\n\r\n## Leaving a Comment\r\n\r\n### Step-by-step\r\n\r\n
\r\nVisual / mouse users\r\n\r\n1. Scroll to the bottom of the issue page\r\n2. Click in the **Leave a comment** text area\r\n3. Type your comment (Markdown is supported - use the toolbar buttons above the text for bold, italic, code, etc.)\r\n4. Optionally click **Preview** to see how it will render\r\n5. Click the green **Comment** button to post\r\n\r\nTo close the issue while commenting: click the arrow on the **Close issue** button and choose **Close with comment**.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nThe comment area is at the bottom of the issue page. At high magnification:\r\n\r\n1. Scroll to the bottom to find the **Leave a comment** text area. At 200%+ zoom, this may require significant scrolling past the timeline.\r\n2. The text area expands as you type. The formatting toolbar above it (bold, italic, code, etc.) wraps at high zoom but remains functional.\r\n3. The **Preview** tab next to **Write** lets you check Markdown rendering before posting.\r\n4. The green **Comment** button is full-width at high zoom and easy to target.\r\n5. **Keyboard shortcut:** Press `Ctrl+Enter` (Windows) or `Cmd+Return` (macOS) from inside the text area to submit the comment without finding the button.\r\n6. In Windows High Contrast mode, the text area border and the Comment button use system colors for clear visibility.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. Navigate to the comment box: `D` → \"Add a comment\" landmark, or press `E` or `F` to focus the text area\r\n2. Enter Focus Mode: NVDA: `Insert+Space` | JAWS: `Insert+Z`\r\n3. Type your comment (plain text or Markdown)\r\n4. To preview: `Tab` to the **Preview** button, press `Enter`; then `Tab` back to **Write** to continue editing\r\n5. Submit: press `Ctrl+Enter` from inside the text area, OR press `Escape` → `Tab` to the **Comment** button → `Enter`\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. Navigate to the comment box: `VO+U` → Landmarks → \"Add a comment\", or Quick Nav `F` to jump to the text area\r\n2. Interact with the text area: `VO+Shift+Down`\r\n3. Type your comment (plain text or Markdown)\r\n4. To preview: `VO+Shift+Up` to stop interacting, then `Tab` to the **Preview** button and `VO+Space`\r\n5. Submit: press `Cmd+Return` from inside the text area, OR `VO+Shift+Up` → `Tab` to the **Comment** button → `VO+Space`\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative - commenting\r\n\r\nLeave a comment from your terminal:\r\n\r\n```bash\r\n# Interactive: opens your default editor ($EDITOR) to write the comment\r\ngh issue comment 42\r\n\r\n# Inline: provide the comment text directly\r\ngh issue comment 42 --body \"Thanks for reporting this. I can reproduce the issue with NVDA + Chrome.\"\r\n```\r\n\r\n
\r\n\r\n### Markdown formatting while typing\r\n\r\nThese keyboard shortcuts work inside the text area (Focus Mode):\r\n\r\n| Shortcut | Result |\r\n| ---------- | -------- |\r\n| `Ctrl+B` | **Bold text** |\r\n| `Ctrl+I` | *Italic text* |\r\n| `Ctrl+E` | `Code span` |\r\n| `Ctrl+K` | [Link text](URL) dialog |\r\n| `Ctrl+Shift+.` | > Blockquote |\r\n| `Ctrl+Shift+L` | - Bullet list |\r\n| `Ctrl+Shift+7` | 1. Numbered list |\r\n\r\n### GitHub shortcuts for the Issues pages\r\n\r\nThese are the GitHub built-in shortcuts for working with issues. Enable Focus Mode first (NVDA: `NVDA+Space`, JAWS: `Insert+Z`) before using single-key shortcuts.\r\n\r\n#### On the Issues list page\r\n\r\n| Shortcut | Action |\r\n| --- | --- |\r\n| `?` | Show all shortcuts for this page |\r\n| `G I` | Jump to the Issues tab from anywhere in the repo |\r\n| `C` | Create a new issue |\r\n\r\n**Shortcut note:** For `G I`, press `G`, release it, then press `I` (two sequential key presses, not simultaneous).\r\n| `Ctrl+/` (Win) or `Cmd+/` (Mac) | Focus the issues search and filter bar |\r\n| `U` | Filter by author |\r\n| `L` | Filter by or edit labels |\r\n| `M` | Filter by or edit milestones |\r\n| `A` | Filter by or edit assignee |\r\n| `O` or `Enter` | Open the selected issue |\r\n\r\n#### On an open issue\r\n\r\n| Shortcut | Action |\r\n| --- | --- |\r\n| `M` | Set a milestone |\r\n| `L` | Apply a label |\r\n| `A` | Set an assignee |\r\n| `X` | Link a related issue from the same repository |\r\n| `R` | Quote selected text in your reply (select text first) |\r\n| `Ctrl+Shift+P` (Win) or `Cmd+Shift+P` (Mac) | Toggle Write and Preview tabs |\r\n| `Ctrl+Enter` | Submit comment from inside the text area |\r\n\r\n> **`R` to quote is a power move:** Select any text in a comment while in Browse Mode (`Shift+Arrow` to select), then press `R`. GitHub puts the quoted text in the comment box as a Markdown blockquote. Much faster than typing `>` manually.\r\n\r\nFor the full shortcut system, see [Screen Reader Cheat Sheet - GitHub Shortcuts section](appendix-b-screen-reader-cheatsheet.md#github-built-in-keyboard-shortcuts).\r\n\r\n1. Navigate to your comment (`3` to jump to comments)\r\n2. Find the \"...\" (ellipsis) menu button near your comment\r\n3. Press `Enter` on \"Edit\" from that menu\r\n4. The comment turns into a text area - switch to Focus Mode\r\n5. Make your changes\r\n6. Tab to \"Update comment\" button → Enter\r\n\r\n### Learning Cards: Leaving a Comment\r\n\r\n**Screen reader users:**\r\n- Press `D` to jump to the \"Add a comment\" landmark, which places focus near the text area; then Enter Focus Mode to start typing\r\n- Use `Ctrl+Enter` to submit your comment directly from inside the text area -- this avoids having to Tab through the formatting toolbar to find the Comment button\r\n- To quote someone's text in your reply, select the text in Browse Mode (`Shift+Arrow`), then press `R`; GitHub inserts it as a blockquote in the comment box automatically\r\n\r\n**Low-vision users:**\r\n- The comment text area expands as you type and is full-width at high zoom, making it easy to target; use `Ctrl+Enter` to submit without hunting for the Comment button\r\n- Use the Preview tab next to Write to check your Markdown formatting in rendered form before posting; bold, code blocks, and links are much easier to proofread there\r\n- Keyboard formatting shortcuts (`Ctrl+B` for bold, `Ctrl+E` for inline code) work inside the text area and save time over clicking small toolbar icons\r\n\r\n**Sighted users:**\r\n- The formatting toolbar above the text area offers bold, italic, code, link, and list buttons; hover for tooltips showing the keyboard shortcut for each\r\n- Use the `R` shortcut to quote selected text -- it creates a blockquote in your reply, making threaded conversations much easier to follow\r\n- The Close with comment option (dropdown arrow on the Close button) lets you leave a final note and close the issue in a single action\r\n\r\n\r\n## Filing a New Issue\r\n\r\n### Navigating to New Issue\r\n\r\n
\r\nVisual / mouse users\r\n\r\nFrom the Issues list page, click the green **New issue** button in the top-right of the issue list. If the repository has templates, a template picker page appears - click **Get started** next to the template that fits your needs, or click **Open a blank issue** to skip templates.\r\n\r\n
\r\n\r\n
\r\nLow vision users (zoom, high contrast)\r\n\r\nThe green **New issue** button is in the top-right of the issue list page. At high magnification:\r\n\r\n- At 200%+ zoom, the button may move below the search bar or wrap to its own line. It remains a prominent green button.\r\n- If the repository has issue templates, a template picker page appears with each template as a card. Template descriptions may truncate at high zoom. Hover over a truncated description for the full text.\r\n- The **Get started** button next to each template is small but uses standard link styling. Press `Tab` to move between templates and their Get started buttons.\r\n- **Open a blank issue** link appears at the bottom of the template list. At high zoom, scroll down to find it.\r\n- In Windows High Contrast mode, the New issue button uses the system button colors and the template cards have visible borders.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\nFrom the Issues list:\r\n\r\n1. Press `K` to navigate links and find the \"New issue\" button/link\r\n2. Press `Enter`\r\n3. If a template picker appears: press `3` to navigate template names, read the description below each, then press `Enter` on \"Get started\" for the right template - or find \"Open a blank issue.\" link if no template fits\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\nFrom the Issues list:\r\n\r\n1. Quick Nav `B` or `VO+U` → Buttons to find the \"New issue\" button\r\n2. `VO+Space` to activate it\r\n3. If a template picker appears: Quick Nav `H` or `VO+Cmd+H` to navigate template names, then `VO+Space` on \"Get started\" for the right template - or Quick Nav `K` to find the \"Open a blank issue\" link\r\n\r\n
\r\n\r\n### Filling Out the Issue Form\r\n\r\nThe issue form has these fields (order may vary depending on the template):\r\n\r\n#### Title field\r\n\r\n1. Find the Title input field (`F` or by landmark)\r\n2. Focus Mode → type a clear, specific title\r\n3. Good title: \"Screen reader announces wrong element count on Issues list with 50+ items\"\r\n4. Bad title: \"Bug with screen reader\"\r\n\r\n#### Description / Body field\r\n\r\n1. Tab to the body text area\r\n2. Focus Mode → type using the Markdown template provided\r\n3. If no template, use this structure:\r\n\r\n```markdown\r\n## What happened\r\n\r\nDescribe what you observed.\r\n\r\n## What I expected\r\n\r\nDescribe what should have happened.\r\n\r\n## How to reproduce\r\n\r\n1. Step one\r\n2. Step two\r\n3. Step three\r\n\r\n## Environment\r\n\r\n- Screen reader: [NVDA 2025.3.3 / JAWS 2026 / VoiceOver macOS Sonoma]\r\n- Browser: [Chrome 124 / Firefox 125 / Safari 17]\r\n- OS: [Windows 11 / macOS 14]\r\n- GitHub interface: [Modern experience (default since Jan 2026) / Classic experience]\r\n\r\n## Additional context\r\n\r\nAny other information, screenshots (with alt text), or links.\r\n```\r\n\r\n### Assigning labels from the sidebar\r\n\r\n> **See also:** [Chapter 09: Labels, Milestones, and Projects](09-labels-milestones-projects.md) covers the full label and milestone system.\r\n\r\nWhile the form is open, the sidebar has dropdowns for Labels, Assignees, and Milestone.\r\n\r\n
\r\nVisual / mouse users\r\n\r\nIn the right sidebar, click the gear icon () next to **Labels**. A dropdown opens - click a label to select it. Click outside to close. Repeat for **Assignees** and **Milestone**.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. `Tab` away from the text area (or press `Escape` to leave Focus Mode)\r\n2. Navigate to the sidebar - press `H` to find \"Labels\" heading\r\n3. Press `Enter` on the Labels gear/button\r\n4. Dropdown opens → `↑/↓` to navigate labels\r\n5. `Enter` to select/deselect\r\n6. `Escape` to close (selections save automatically)\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. `VO+Shift+Up` to stop interacting with the text area\r\n2. `VO+U` → Headings to find the \"Labels\" heading in the sidebar\r\n3. `VO+Space` on the Labels gear/button to open the dropdown\r\n4. `VO+Down` or arrow keys to navigate labels\r\n5. `VO+Space` to select/deselect\r\n6. `Escape` to close (selections save automatically)\r\n\r\n
\r\n\r\n### Submitting the issue\r\n\r\n1. Tab to \"Submit new issue\" button\r\n2. Press `Enter`\r\n\r\n
\r\nGitHub CLI (gh) alternative - filing a new issue\r\n\r\nCreate an issue from your terminal:\r\n\r\n```bash\r\n# Interactive: prompts for title, body, labels, and assignees\r\ngh issue create\r\n\r\n# Inline: provide everything on the command line\r\ngh issue create --title \"Screen reader announces wrong count on Issues list\" \\\r\n --body \"## What happened\\n\\nThe count says 14 but only 12 issues are visible.\" \\\r\n --label \"bug,accessibility\" \\\r\n --assignee @me\r\n\r\n# Use a template (if the repo has issue templates)\r\ngh issue create --template \"bug_report.md\"\r\n```\r\n\r\nThe interactive mode walks you step-by-step through title, body (opens your editor), labels, and assignees - fully usable from a terminal with a screen reader.\r\n\r\n
\r\n\r\n### Learning Cards: Filing a New Issue\r\n\r\n
\r\nScreen reader users\r\n\r\n- After pressing \"New issue,\" if a template picker appears, press `3` to jump between template names; each has a \"Get started\" link next to it\r\n- In the title field, type at least 12 characters for a meaningful title; press `Tab` to move to the body field\r\n- Press `Ctrl+Enter` from inside the body text area to submit the issue without needing to find the Submit button\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- The green \"New issue\" button is in the top-right of the Issues list page; at 200%+ zoom it may wrap below the search bar\r\n- Template cards (if the repo uses them) show truncated descriptions at high zoom; hover over them for the full text\r\n- The sidebar dropdowns for Labels, Assignees, and Milestone are gear icons that may be small at high zoom; they open searchable dropdown panels\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- The new issue form has a Title field at the top and a large Body text area below; a formatting toolbar (bold, italic, code, etc.) appears above the body\r\n- The Write/Preview tabs above the body let you toggle between editing and rendered Markdown views\r\n- Sidebar options (Labels, Assignees, Milestone) appear to the right of the body field; click the gear icon next to each to open a dropdown\r\n\r\n
\r\n\r\n### Tool Cards: File a New Issue\r\n\r\n**github.com (browser):**\r\n1. Navigate to the repository's **Issues** tab (or press `G` then `I`).\r\n2. Click **New issue**, choose a template or blank issue.\r\n3. Fill in the title and description, then click **Submit new issue**.\r\n\r\n**github.dev (web editor):**\r\nNot available -- issues are managed through the repository's Issues tab, not the code editor.\r\n\r\n**VS Code Desktop (GitHub Pull Requests extension):**\r\n1. Open the **GitHub** panel in the sidebar.\r\n2. Under **Issues**, click the **+** icon to create a new issue.\r\n3. Fill in the title and body, then click **Create**.\r\n\r\n**GitHub Desktop:**\r\nNot directly supported. Click **Repository > View on GitHub** to open the browser, then file the issue there.\r\n\r\n**Git CLI / GitHub CLI:**\r\n```bash\r\ngh issue create --title \"Your title\" --body \"Description here\"\r\n# Or interactively:\r\ngh issue create\r\n```\r\n\r\n\r\n## Cross-Referencing Issues\r\n\r\nLinking issues and PRs to each other creates a trail of context that helps everyone understand the project's history.\r\n\r\n### Closing keywords in PR descriptions or issue comments\r\n\r\nWhen you type these phrases in a PR description or comment (followed by an issue number), GitHub creates a connection:\r\n\r\n| Keyword | Effect on merge |\r\n| --------- | ---------------- |\r\n| `Closes #42` | Closes issue #42 when the PR merges |\r\n| `Fixes #42` | Same - typically for bugs |\r\n| `Resolves #42` | Same - general use |\r\n| `refs #42` | Creates a reference without auto-closing |\r\n| `cc @username` | Notifies the person |\r\n\r\n### Mentioning another issue in a comment\r\n\r\nSimply type `#` followed by a number anywhere in a comment body. GitHub autocompletes with a dropdown of matching issues and PRs:\r\n\r\n```text\r\nStep 1: Type # in the comment box (Focus Mode)\r\nStep 2: A dropdown appears with issues and PRs\r\nStep 3: ↑/↓ to navigate, or type more numbers to filter\r\nStep 4: Enter to insert the reference\r\n```\r\n\r\n### Cross-repo references\r\n\r\n`owner/repo#42` - references issue #42 in a different repository.\r\n\r\n### Learning Cards: Cross-Referencing Issues\r\n\r\n**Screen reader users:**\r\n- Type `#` in any comment body to trigger GitHub's autocomplete dropdown; press `Down Arrow` to browse matching issues and `Enter` to insert the reference link\r\n- Use `Closes #42` (not just `#42`) in PR descriptions so GitHub automatically closes the issue on merge; your screen reader will confirm the link is created in the PR timeline\r\n- Cross-references appear as timeline events on the linked issue; navigate with `H` to find \"mentioned this issue\" entries to trace the conversation history\r\n\r\n**Low-vision users:**\r\n- Cross-reference links (`#42`) render as colored, clickable links in both issue bodies and PR descriptions; at high zoom they remain inline with surrounding text\r\n- The autocomplete dropdown triggered by `#` may overlap content at high magnification; type additional digits to narrow results and reduce dropdown size\r\n- Back-links appear automatically on the referenced issue's timeline, so you can verify the connection was created by visiting either side\r\n\r\n**Sighted users:**\r\n- Use `Closes #42`, `Fixes #42`, or `Resolves #42` in PR descriptions for auto-closing on merge; `refs #42` creates a reference without auto-close, useful for \"related but not solved\" links\r\n- GitHub's autocomplete (`#` then type) searches both issue titles and numbers, so you can find issues by keyword without memorizing numbers\r\n- Cross-repo references use the format `owner/repo#42` -- useful when your PR in one repository fixes a bug tracked in another\r\n\r\n\r\n## Sub-Issues - Parent and Child Relationships\r\n\r\n**Sub-issues** (released 2025) let you nest issues inside a parent issue to break large work into tracked pieces. A \"parent\" issue contains a list of child issues; each child is a full issue with its own discussion, labels, and assignees.\r\n\r\n### When to Use Sub-Issues\r\n\r\n| Use case | Example |\r\n| ---------- | --------- |\r\n| Large feature broken down | Parent: \"Redesign navigation\"; Children: \"Keyboard nav,\" \"Screen reader nav,\" \"Mobile nav\" |\r\n| Epic tracking | Parent: \"WCAG 2.1 AA compliance\"; Children: one issue per failing criterion |\r\n| Release milestone | Parent: \"v2.0 release\"; Children: every required PR/fix |\r\n\r\n### Creating a Sub-Issue\r\n\r\nFrom any open issue:\r\n\r\n```text\r\n1. Open the parent issue page\r\n2. Scroll to (or H-navigate to) the \"Sub-issues\" section in the issue body/sidebar\r\n3. Tab to \"Add sub-issue\" button → Enter\r\n4. Type the issue number or title to search\r\n5. Select the issue from the dropdown → Enter to link\r\n Or: select \"Create new issue\" to create and link in one step\r\n```\r\n\r\n**Screen reader note:** The sub-issues section is announced as a region. After linking, the child issue appears as a list item with a checkbox showing its open/closed state. Tab through to read each child's title and status.\r\n\r\n### Reading Sub-Issues on a Parent Issue\r\n\r\n```text\r\nH → \"Sub-issues\" heading\r\n↓ → list of linked child issues\r\nEach item: [checkbox state] [issue title] [#number] [open/closed badge]\r\nTab → \"Add sub-issue\" button (if you have write access)\r\n```\r\n\r\n**Progress indicator:** The parent issue shows a completion bar (e.g., \"3 of 7 completed\") based on how many child issues are closed. Screen readers announce this as a progress region.\r\n\r\n### Viewing a Child Issue's Parent\r\n\r\nEvery child issue shows a \"Parent issue\" link near the top of the page (above the description). Navigate with `H` or links (`K`) to find it.\r\n\r\n### Sub-Issues vs. Task Lists\r\n\r\n| Feature | Task list checkboxes | Sub-issues |\r\n| --------- | --------------------- | ------------ |\r\n| Location | Issue description (Markdown) | Sidebar/section (structured data) |\r\n| Each item is | Text line + checkbox | A full GitHub issue |\r\n| Tracked in Projects | No (checkbox only) | Yes (each child tracks independently) |\r\n| Cross-repo | No | Yes |\r\n| Best for | Quick checklists in one issue | Multi-issue work tracking |\r\n\r\n> **Workshop tip:** If you are working on a feature that requires multiple PRs or involves several team members, ask the maintainer to create a parent issue. You can then claim individual child issues without one person owning the whole feature.\r\n\r\n### Learning Cards: Sub-Issues\r\n\r\n**Screen reader users:**\r\n- The sub-issues section is announced as a region; press `H` to navigate to the \"Sub-issues\" heading, then arrow down through the list where each child announces its checkbox state, title, and open/closed badge\r\n- The parent issue shows a progress indicator (\"3 of 7 completed\") announced as a progress region; listen for this after the sub-issues heading to gauge overall status\r\n- Every child issue includes a \"Parent issue\" link near the top of its page; navigate with `K` (links) to find it and jump back to the parent quickly\r\n\r\n**Low-vision users:**\r\n- The completion progress bar on the parent issue uses color to show progress; in high-contrast mode, completed vs. remaining segments use distinct system colors\r\n- At high zoom, the \"Add sub-issue\" button may wrap below the sub-issues list; Tab past the last child item to reach it\r\n- Each child issue's open/closed badge uses both color and text (\"Open\" or \"Closed\"), so status is readable without relying on color alone\r\n\r\n**Sighted users:**\r\n- Sub-issues appear as a checklist with a progress bar on the parent issue; each child links directly to its own issue page with full discussion and labels\r\n- Use sub-issues instead of Markdown task-list checkboxes when each item needs its own assignee, labels, or cross-repo tracking -- sub-issues are structured data, not just text\r\n- Creating a sub-issue from the parent's \"Add sub-issue\" button auto-links the new issue; you can also link existing issues by searching their number or title\r\n\r\n\r\n## Managing Issues (for Maintainers and Triagers)\r\n\r\n### Closing an issue\r\n\r\n
\r\nVisual / mouse users\r\n\r\nScroll to the bottom of the issue page. Click the **Close issue** button next to the comment box. Optionally type a closing comment first. If you want to record a reason, click the dropdown arrow on the button and choose **Close as completed** or **Close as not planned**.\r\n\r\n
\r\n\r\n
\r\nScreen reader users (NVDA / JAWS - Windows)\r\n\r\n1. **Keyboard shortcut (fastest):** Navigate to the comment text area (`D` → \"Add a comment\" landmark), switch to Focus Mode, then press `Ctrl+Shift+Enter` to close the issue\r\n2. **Button approach:** `Tab` to the \"Close issue\" button (at the bottom of the page, near the comment box) and press `Enter`\r\n3. Optionally leave a closing comment first\r\n\r\n
\r\n\r\n
\r\nScreen reader users (VoiceOver - macOS)\r\n\r\n1. **Keyboard shortcut (fastest):** `VO+U` → Landmarks → \"Add a comment\", interact with the text area (`VO+Shift+Down`), then press `Cmd+Shift+Return` to close the issue\r\n2. **Button approach:** Quick Nav `B` or `Tab` to find the \"Close issue\" button, then `VO+Space`\r\n3. Optionally leave a closing comment first\r\n\r\n
\r\n\r\n
\r\nGitHub CLI (gh) alternative - closing and reopening\r\n\r\nClose or reopen an issue from your terminal:\r\n\r\n```bash\r\n# Close an issue\r\ngh issue close 42\r\n\r\n# Close with a reason\r\ngh issue close 42 --reason \"completed\"\r\ngh issue close 42 --reason \"not planned\"\r\n\r\n# Close with a comment\r\ngh issue close 42 --comment \"Fixed in PR #45.\"\r\n\r\n# Reopen a closed issue\r\ngh issue reopen 42\r\n```\r\n\r\n
\r\n\r\n### Reopening a closed issue\r\n\r\nIf an issue is Closed, the \"Close issue\" button becomes \"Reopen issue\" - navigate and activate to reopen.\r\n\r\n### Assigning an issue\r\n\r\nFrom the issue sidebar:\r\n\r\n1. Navigate to \"Assignees\" heading (`3` or `H`)\r\n2. Activate the gear/plus button\r\n3. Type a username in the search field\r\n4. Select from the dropdown\r\n\r\n
\r\nGitHub CLI (gh) alternative - assigning and labeling\r\n\r\nManage assignments and labels from your terminal:\r\n\r\n```bash\r\n# Assign yourself\r\ngh issue edit 42 --add-assignee @me\r\n\r\n# Add labels\r\ngh issue edit 42 --add-label \"accessibility,in progress\"\r\n\r\n# Remove a label\r\ngh issue edit 42 --remove-label \"needs triage\"\r\n\r\n# Set a milestone\r\ngh issue edit 42 --milestone \"Hackathon Day 1\"\r\n```\r\n\r\n
\r\n\r\n### Changing labels\r\n\r\nFrom the issue sidebar:\r\n\r\n1. Navigate to \"Labels\" heading\r\n2. Activate the gear button\r\n3. Select/deselect labels from the dropdown\r\n4. Press Escape to save\r\n\r\n### Transferring or deleting an issue\r\n\r\nAvailable from the \"...\" (ellipsis) button at the top of the issue - navigate buttons with `B` to find it.\r\n\r\n### Learning Cards: Managing Issues\r\n\r\n**Screen reader users:**\r\n- Close an issue instantly with `Ctrl+Shift+Enter` from the comment text area (Focus Mode) -- no need to Tab to the Close button\r\n- The sidebar sections (Assignees, Labels, Milestone) each have their own heading; press `H` or `3` to jump between them, then activate the gear icon to open each dropdown\r\n- Use `gh issue edit 42 --add-label \"accessibility\" --add-assignee @me` to batch-update labels and assignments from the terminal without navigating sidebar controls\r\n\r\n**Low-vision users:**\r\n- Sidebar controls (Assignees, Labels, Milestone) are narrow at default width; at high zoom they stack vertically and each dropdown opens a searchable overlay that is easier to read\r\n- The Close issue button turns green and its label changes to \"Reopen issue\" once closed; in high-contrast mode, both states use distinct system colors\r\n- Type in the search field inside each sidebar dropdown (Labels, Assignees) to filter long lists rather than scrolling through all options at high magnification\r\n\r\n**Sighted users:**\r\n- The issue sidebar on the right contains Assignees, Labels, Projects, and Milestone in collapsible sections; click the gear icon next to each to open the edit dropdown\r\n- Use the dropdown arrow on the Close button to choose \"Close as completed\" vs. \"Close as not planned\" -- this distinction helps with project tracking and search filtering\r\n- The \"...\" menu at the top of any issue provides Transfer, Pin, Lock, and Delete options for repository maintainers\r\n\r\n\r\n## The \"good first issue\" Label - Your Entry Point\r\n\r\nWhen looking for your first open source contribution:\r\n\r\n1. Navigate to any project's Issues tab\r\n2. Filter by label: type `is:open label:\"good first issue\"` in the search\r\n3. Read through issues until you find one in your area of interest\r\n4. Comment on the issue: \"Hi, I'd like to work on this. Can I be assigned?\"\r\n5. Wait for a maintainer to respond and assign you before starting work\r\n\r\n**Remember:** It's respectful to ask before starting. Maintainers juggle many discussions and need to know who is working on what to avoid duplicated effort.\r\n\r\n### Learning Cards: The \"good first issue\" Label\r\n\r\n**Screen reader users:**\r\n- Use the filter query `is:open label:\"good first issue\"` in the search bar to jump directly to beginner-friendly issues; `gh issue list --label \"good first issue\"` does the same in the terminal\r\n- Before claiming an issue, read existing comments to check whether someone else has already been assigned; listen for \"assigned to\" in the sidebar metadata\r\n- When you comment to claim an issue, include a sentence about your approach so the maintainer can give early feedback before you start coding\r\n\r\n**Low-vision users:**\r\n- The \"good first issue\" label renders with a distinct background color (typically light purple or teal); in high-contrast mode it uses system highlight colors with readable text\r\n- Filter results may include issues with multiple labels stacked together; at high zoom, labels wrap to a second line but remain readable\r\n- Bookmark the filtered URL (`/issues?q=is:open+label:\"good first issue\"`) in your browser for one-click access to beginner issues across your favorite repositories\r\n\r\n**Sighted users:**\r\n- The \"good first issue\" label is a GitHub convention recognized across the ecosystem; many projects also use \"help wanted\" for intermediate tasks\r\n- Always comment before starting work -- even if unassigned -- to avoid duplicating effort with another contributor who may already be working quietly\r\n- Read the issue's linked PR history (if any) to see whether previous attempts were made and why they were closed; this saves you from repeating known dead ends\r\n\r\n\r\n## Accessibility-Specific Issue Writing Tips\r\n\r\nWhen filing accessibility bugs, these details help maintainers reproduce and fix the problem:\r\n\r\n1. **Screen reader and version** - \"NVDA 2025.3.3\" not just \"screen reader\"\r\n2. **OS and version** - \"Windows 11 22H2\"\r\n3. **Browser and version** - \"Chrome 124.0.6367.82\"\r\n4. **GitHub interface** - \"Modern experience (default since Jan 2026)\" or \"Classic experience (opted out)\"\r\n5. **What was announced** - quote the exact text your screen reader spoke\r\n6. **What should have been announced** - describe the expected behavior\r\n7. **ARIA issue if known** - e.g., \"The button has no accessible name\"\r\n8. **Steps to reproduce** - numbered, step-by-step\r\n9. **Frequency** - \"This happens every time\" vs \"intermittent\"\r\n\r\n### Example of a well-filed accessibility issue\r\n\r\n```text\r\nTitle: Issues list does not announce label filtering results to screen readers\r\n\r\n## What happened\r\nWhen I apply a label filter on the Issues list using the Labels dropdown,\r\nthe filtered list updates visually but NVDA does not announce that the\r\nresults changed or how many items are now shown.\r\n\r\n## What I expected\r\nAfter filtering, the screen reader should announce something like\r\n\"14 issues open, filtered by label: accessibility\" or a live region\r\nupdate indicating the results changed.\r\n\r\n## How to reproduce\r\n1. Navigate to any repo's Issues tab\r\n2. Press B to navigate to the \"Label\" filter button\r\n3. Press Enter to open the dropdown\r\n4. Select the \"accessibility\" label\r\n5. Press Escape to close\r\n6. Notice: no announcement that filtering has been applied\r\n\r\n## Environment\r\n- Screen reader: NVDA 2025.3.3 (with NVDA+Chrome)\r\n- Browser: Chrome 124.0.6367.82\r\n- OS: Windows 11 22H2\r\n- GitHub interface: Modern experience (default since Jan 2026)\r\n\r\n## Additional context\r\nJAWS 2026 also does not announce. VoiceOver on macOS Sonoma with\r\nSafari 17 does announce \"List updated\" when filtering is applied,\r\nso the macOS behavior appears correct.\r\n```\r\n\r\n### Learning Cards: Accessibility-Specific Issue Writing\r\n\r\n**Screen reader users:**\r\n- Always quote the exact text your screen reader announced in the issue body; wrap it in a fenced code block so readers know it is literal output, not your description\r\n- Include your screen reader name and version (e.g., \"NVDA 2025.3.3\") plus browser and OS; this lets maintainers reproduce with the same toolchain\r\n- Test with a second screen reader or browser if possible and note the results -- \"Also fails in JAWS 2026 with Chrome; works in VoiceOver with Safari\" dramatically narrows the debugging scope\r\n\r\n**Low-vision users:**\r\n- When filing zoom or contrast bugs, state your exact zoom level and whether you use Windows High Contrast, macOS Increase Contrast, or a browser extension\r\n- Screenshots are powerful evidence; annotate them (circle the problem area, add a text callout) and always include alt text describing what the screenshot shows\r\n- Note whether the issue occurs only at certain zoom levels or viewport widths; a bug at 400% that disappears at 200% points to a CSS breakpoint problem\r\n\r\n**Sighted users:**\r\n- Even if you do not use assistive technology, you can file accessibility issues by testing with keyboard-only navigation (Tab, Enter, Escape) and noting where focus is lost or trapped\r\n- Include the ARIA role or attribute involved if you can identify it from browser DevTools (e.g., \"The button has `role=presentation` and no accessible name\")\r\n- Link to the relevant WCAG success criterion when possible (e.g., \"Fails WCAG 2.1 SC 1.3.1 Info and Relationships\"); this gives maintainers a clear standard to design against\r\n\r\n\r\n## Writing Effective Issues\r\n\r\n> **See also:** [Appendix N: Advanced Search](appendix-n-advanced-search.md) covers search qualifiers to find existing issues before filing a new one.\r\n\r\nA well-written issue saves everyone time -- the maintainer who reads it, the contributor who fixes it, and the future searcher who finds it six months later. This section gives you reusable templates for the two most common issue types and a set of principles that apply to every issue you file.\r\n\r\n### Bug Report Structure\r\n\r\nA strong bug report answers five questions. Use this template every time you report something broken.\r\n\r\n| Section | What to write |\r\n|---|---|\r\n| **Title** | Follow the formula: \"When I [action], [unexpected result] instead of [expected result]\" |\r\n| **Steps to Reproduce** | Numbered list -- start from the earliest relevant step |\r\n| **Expected Behavior** | What *should* happen according to documentation or common sense |\r\n| **Actual Behavior** | What *does* happen -- include exact error messages or screenshots |\r\n| **Environment** | OS, browser, screen reader, app version -- anything that might matter |\r\n\r\nThe title formula is the most important part. A title like \"When I press Enter on the Submit button, nothing happens instead of creating the issue\" tells the maintainer exactly what is broken before they even open the issue.\r\n\r\n> **Screen reader tip:** When pasting error messages into the Actual Behavior section, wrap them in a fenced code block (triple backticks). Screen readers will announce \"code block\" so the listener knows the text is a literal error, not your description.\r\n\r\n**Steps to Reproduce matter more than you think.** Maintainers cannot fix what they cannot recreate. Number every step, starting from a clean slate -- \"Open the repository\" is better than \"Go to the page.\" Include what you clicked, what keyboard shortcut you pressed, and what happened after each step.\r\n\r\n### Feature Request Structure\r\n\r\nFeature requests work best when they focus on the *problem* before jumping to the solution. Use this four-part structure:\r\n\r\n1. **Problem statement** -- Describe the pain point. What are you trying to do, and why is it hard or impossible right now?\r\n2. **Proposed solution** -- Your best idea for fixing the problem. Be specific enough to discuss, but hold it loosely.\r\n3. **Alternatives considered** -- Other approaches you thought about and why they fell short. This shows you have done your homework.\r\n4. **Who benefits** -- Name the audience. \"Screen reader users navigating large repositories\" is more compelling than \"everyone.\"\r\n\r\nA feature request that starts with \"I want a dark mode toggle\" is weaker than one that starts with \"Low-vision users report eyestrain after 20 minutes because the current theme has insufficient contrast.\" The second version gives maintainers something to design around.\r\n\r\n### General Issue Writing Principles\r\n\r\nThese rules apply to every issue -- bugs, features, questions, and everything in between.\r\n\r\n**One issue per problem.** If you discovered two bugs during the same session, file two separate issues. Combining them makes it impossible to close one without the other and clutters the conversation.\r\n\r\n**Write searchable titles.** Future contributors will search before filing. \"Bug with button\" will never surface in a search for \"Submit button unresponsive on Safari.\" Front-load the title with the specific component or action.\r\n\r\n**Include context, not assumptions.** Instead of \"The API is broken,\" write \"The `/repos` endpoint returns a 403 when I pass a valid token.\" Let maintainers draw their own conclusions from the evidence you provide.\r\n\r\n**Link related issues.** If your bug might be connected to issue #42, mention it: \"This might be related to #42.\" GitHub automatically creates a back-link, building a web of context that helps everyone. You will learn more about cross-referencing in [Chapter 6](06-working-with-pull-requests.md).\r\n\r\n| Principle | Bad example | Good example |\r\n|---|---|---|\r\n| One issue per problem | \"The button is broken and also the logo is wrong\" | Two separate issues, each with its own title |\r\n| Searchable title | \"Help needed\" | \"Keyboard focus lost after closing modal dialog\" |\r\n| Context over assumptions | \"Nothing works\" | \"After upgrading to v2.3, the dashboard returns a blank page on Firefox 124\" |\r\n| Link related issues | (no mention) | \"Possibly related to #42 -- same component, different trigger\" |\r\n\r\n### Before and After: A Vague Issue vs. a Clear Issue\r\n\r\n**Vague issue (hard to act on):**\r\n\r\n> **Title:** Bug\r\n>\r\n> It doesn't work. I tried clicking and nothing happened. Please fix.\r\n\r\nThe maintainer has to ask: What doesn't work? Where did you click? What browser? What did you expect? Every follow-up question costs a round-trip of waiting.\r\n\r\n**Clear issue (ready to fix):**\r\n\r\n> **Title:** When I press Enter on the \"New issue\" button, nothing happens instead of opening the issue form\r\n>\r\n> **Steps to Reproduce:**\r\n> 1. Navigate to github.com/org/repo\r\n> 2. Press `G` then `I` to go to the Issues tab\r\n> 3. Tab to the \"New issue\" button\r\n> 4. Press `Enter`\r\n>\r\n> **Expected:** The new issue form opens.\r\n>\r\n> **Actual:** The page does not respond. No error in the console.\r\n>\r\n> **Environment:** Windows 11, Firefox 128, JAWS 2025\r\n\r\nThe maintainer can reproduce this in under a minute. No follow-up questions needed -- the fix can start immediately.\r\n\r\n> **Screen reader tip:** You can use the issue template feature in GitHub to pre-fill these sections automatically. If the repository provides templates, your screen reader will announce each section heading as you Tab through the form. You will set up your own issue templates in [Chapter 17](17-issue-templates.md).\r\n\r\n### Learning Cards: Writing Effective Issues\r\n\r\n
\r\nScreen reader users\r\n\r\n- Use fenced code blocks (triple backticks) when pasting error messages or screen reader output; your screen reader announces \"code block\" so listeners know the text is literal, not description\r\n- When writing \"Steps to Reproduce,\" type each step as a numbered Markdown list item (`1.`, `2.`, etc.) so screen readers announce \"list with N items\"\r\n- Type `#` in the comment body to trigger issue autocomplete; press `Down Arrow` to navigate matching issues and `Enter` to insert a cross-reference link\r\n\r\n
\r\n\r\n
\r\nLow vision users\r\n\r\n- Use the Preview tab (next to Write) to check your Markdown rendering before submitting; headings, bold text, and code blocks are much easier to proofread in rendered form\r\n- Screenshots with alt text are valuable evidence; add them with the image button in the formatting toolbar or drag-and-drop into the body field\r\n- Keep paragraphs short (3-4 sentences max) so the issue is scannable at high zoom without excessive scrolling\r\n\r\n
\r\n\r\n
\r\nSighted users\r\n\r\n- A well-structured issue uses H2 headings (##) for major sections: What happened, Expected, How to reproduce, Environment\r\n- GitHub renders Markdown tables in issue bodies; use a table to compare expected vs. actual behavior side by side\r\n- The title appears in issue lists, email notifications, and search results; front-load it with the specific component or action for discoverability\r\n\r\n
\r\n\r\n\r\n## Try It: File Your First Issue\r\n\r\n**Time:** 3 minutes | **What you need:** Browser, signed in to GitHub\r\n\r\nGo to the Learning Room repository and file a real issue:\r\n\r\n1. Navigate to the Issues tab (press `G` then `I` in Focus Mode)\r\n2. Find and activate the \"New issue\" button (`K` to links, or `Tab` to it)\r\n3. In the title field, type: **\"Introduce myself - [Your Name]\"**\r\n4. In the description, write 2-3 sentences: who you are, what screen reader you use, and one thing you're hoping to learn today\r\n5. Press `Ctrl+Enter` to submit (or Tab to the Submit button and press `Enter`)\r\n\r\n**You're done.** You just filed your first GitHub issue. Go read someone else's introduction and leave a friendly comment - press `3` to jump between issue titles on the Issues list.\r\n\r\n> **What success feels like:** Your issue is live. Other participants can see it. You just contributed to a real repository - and it took less than three minutes.\r\n\r\n### Learning Cards: Filing Your First Issue\r\n\r\n**Screen reader users:**\r\n- After pressing `Ctrl+Enter` to submit, listen for the page reload; GitHub navigates to your new issue page where the title is the first heading -- press `1` to confirm it matches what you typed\r\n- Navigate the issue list with `3` (heading level 3) to jump between issue titles; this is faster than arrowing through every element on the page\r\n- If the template picker appears, use `Tab` and `Enter` to select \"Open a blank issue\"; template names are announced as link text\r\n\r\n**Low-vision users:**\r\n- The \"New issue\" button is prominent and green on the Issues list page; at high zoom it remains visible near the top of the page and does not collapse into a menu\r\n- The title field is full-width and the body field expands as you type; both are easy to locate and target at any zoom level\r\n- After submitting, your new issue page shows your avatar, title, and description in high-contrast-friendly layout; verify the content rendered correctly before moving on\r\n\r\n**Sighted users:**\r\n- Your issue immediately appears at the top of the Issues list; the green \"Open\" badge confirms it was created successfully\r\n- Read a few other students' introduction issues and leave a comment to practice the commenting workflow from the Leaving a Comment section\r\n- Notice how the issue number (e.g., #150) is auto-assigned and appears in the URL and page title; you will use this number for cross-references later\r\n\r\n\r\n> ### Day 2 Amplifier - Accessibility Agents: `@issue-tracker`\r\n>\r\n> **File, read, comment on, and triage real issues manually before using any agent.** If you have not done the triage work yourself - reading descriptions, assigning labels, identifying duplicates - you cannot evaluate whether an agent's priority scoring is correct. The skill must exist before the amplifier is useful.\r\n>\r\n> Once you have mastered manual issue management:\r\n>\r\n> - **In VS Code** - `@issue-tracker find open issues labeled good-first-issue` searches cross-repository with community sentiment scoring, release-awareness prioritization, and batch-reply capability across every repo you have access to\r\n> - **In your repo** - The issue templates in `accessibility-agents/.github/ISSUE_TEMPLATE/` structure both human filing and automated triage; fork [accessibility-agents](https://github.com/Community-Access/accessibility-agents) and that structure travels into any project you lead\r\n> - **In the cloud** - GitHub Agentic Workflows triage new issues the moment they are opened: applying labels, posting first-response comments, adding to Project boards - the same triage actions you practiced manually today, running at scale\r\n>\r\n> *Today you are the triage engine. On Day 2, you understand the engine well enough to direct it.*\r\n\r\n\r\n> **Challenge Time:** It's time for the real deal. Go to the [Challenge Hub](CHALLENGES.md) and complete **Challenge 2: File Your First Issue** and **Challenge 3: Join the Conversation**. When Aria the bot replies to you, she will tell you when it's time to move to [Chapter 06: Working with Pull Requests](06-working-with-pull-requests.md).\r\n\r\n---\r\n\r\n\r\n*Next: [Chapter 06: Working with Pull Requests](06-working-with-pull-requests.md)* \r\n*Back: [Chapter 04: The Learning Room](04-the-learning-room.md)* \r\n*Related appendices: [Appendix N: Advanced Search](appendix-n-advanced-search.md) | [Appendix V: GitHub Mobile](appendix-v-github-mobile.md)*\r\n\r\n\r\n\r\n\r\n" + } + ] +} diff --git a/podcasts/logs/agentic-pilots/ep20-accessibility-standards.packet.json b/podcasts/logs/agentic-pilots/ep20-accessibility-standards.packet.json new file mode 100644 index 0000000..8023f42 --- /dev/null +++ b/podcasts/logs/agentic-pilots/ep20-accessibility-standards.packet.json @@ -0,0 +1,135 @@ +{ + "generatedAt": "2026-05-13T01:47:32.806Z", + "kind": "companion", + "slug": "ep20-accessibility-standards", + "title": "Episode 20: Accessibility Standards Reference", + "description": "WCAG 2.2, ARIA roles, and the PR accessibility checklist.", + "transcriptPath": "S:\\code\\git-going-with-github\\podcasts\\scripts\\appendices\\ep20-accessibility-standards.txt", + "chapterPlanPath": "S:\\code\\git-going-with-github\\podcasts\\transcripts\\appendices\\ep20-accessibility-standards-chapters.json", + "transcriptText": "[ALEX]\nWelcome to Git Going with GitHub, episode 20: Accessibility Standards Reference. I am Alex. Today we are going to make Accessibility Standards Reference something you can explain, practice, and recover from when the interface surprises you.\n\n[JAMIE]\nAnd I am Jamie. I will be the voice of the learner who is willing to ask, what is this for, where am I, and how do I know I did it right?\n\n[PAUSE]\n\n[ALEX]\nThe big idea today: WCAG 2.2, ARIA roles, and the PR accessibility checklist. We will name the concept, explain why it matters, practice the move, and point out the checks that tell you the work is real.\n\n[JAMIE]\nSo the episode should work even if someone has not read the chapter yet.\n\n[ALEX]\nExactly. The transcript has to stand on its own. It can point toward practice, but it should teach the concept right here in the conversation.\n\n[PAUSE]\n\n[JAMIE]\nOkay, set the room for us. What are we walking into?\n\n[ALEX]\nWCAG, ARIA, and What They Mean for Your Contributions: This appendix gives you a working understanding of the accessibility standards that govern the web, GitHub's interface, and the projects you will contribute to. The next useful detail is concrete: You do not need to memorize these - use this as a lookup when a PR review mentions a specific standard or success criterion.\n\n[ALEX]\nThe next layer is this. Here is the learner-facing version. WCAG (Web Content Accessibility Guidelines) is organized around four principles, often abbreviated POUR. Put another way, every WCAG success criterion belongs to one of these four principles. A good GitHub workflow is like a well-run meeting: everyone knows the topic, the next action, and who has the floor.\n\n[ALEX]\nA solid pull request habit is to separate three questions: what changed, why it changed, and what still needs review. That keeps the conversation useful instead of noisy.\n\n[JAMIE]\nWhat is the one idea that makes the next few steps less mysterious?\n\n[ALEX]\nLearning Cards: WCAG Overview has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThat shows up in the workshop in a few specific ways. WCAG is organized around four principles: Perceivable, Operable, Understandable, Robust (POUR) -- use this mnemonic when reviewing any PR. Most projects target WCAG 2.2 AA -- when a reviewer cites a criterion number like 1.4.3, search the tables in Section 3 of this appendix. The WCAG Quick Reference (Section 10) is a filterable web page -- use your screen reader's find command to jump to any criterion number. The tables in this appendix use pipe-delimited Markdown -- increase your editor font size or use a Markdown preview for cleaner column alignment. WCAG 1.4.3 (contrast) and 1.4.11 (non-text contrast) are the criteria most relevant to your daily experience -- bookmark them. When checking contrast ratios, use the WebAIM Contrast Checker link in Section 10 with your browser zoom set to your preferred level.\n\n[JAMIE]\nThat feels much more doable when you say it as one move.\n\n[ALEX]\nRight. The magic is not speed. The magic is knowing what changed and why it matters.\n\n[PAUSE]\n\n[ALEX]\nNow bring the learner back to the room. Anchor this part on 2. Conformance Levels: A, AA, AAA. Most open source projects, and GitHub itself, target WCAG 2.2 AA compliance. This is the part to say slowly: When you file an accessibility bug or review a PR, AA is the standard to reference.\n\n[JAMIE]\nWhat would you say to someone who is already bracing for this to be too much?\n\n[ALEX]\nThe reason this matters is simple: these are the criteria you will most commonly encounter when contributing to web projects or reviewing GitHub interface changes.\n\n[ALEX]\nThe useful habit is simple: orient, act, verify, then continue. That pause between action and trust is part of the work.\n\n[ALEX]\nThat matters because of the next idea. Do not treat 4. ARIA - Roles, States, and Properties as decoration. WAI-ARIA (Accessible Rich Internet Applications) fills the gap between what HTML natively expresses and what complex interactive widgets require. The workshop is closer to rehearsal than lecture. You hear the move, try the move, and then check what changed.\n\n[PAUSE]\n\n[JAMIE]\nHow would you walk the room through that step by step?\n\n[ALEX]\nImportant rules has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nStart here: Don't use ARIA if native HTML suffices. A is already a button - adding role=\"button\" to a is only needed when HTML semantics cannot be used. Then: All interactive ARIA widgets must be keyboard operable. Adding role=\"button\" means you must also handle Enter and Space keypresses in JavaScript. Next: ARIA only affects the accessibility tree. It does not add visual styling or behavior - it only changes what assistive technologies announce. The sequence works because every action has a confirmation.\n\n[ALEX]\nThis is where the talk moves from concept to action. Put 5. ARIA Landmark Roles into plain language. Landmarks let screen reader users jump directly to major sections of a page. The useful version is: GitHub uses these extensively; screen reader users navigate between them with D (NVDA/JAWS) or the Rotor (VoiceOver).\n\n[JAMIE]\nNow it sounds like a workflow instead of a wall of instructions.\n\n[ALEX]\nThat is where confidence comes from: not from never getting lost, but from knowing how to recover.\n\n[ALEX]\nA solid navigation habit is to prove where you are before activating controls. Headings, landmarks, and the address bar are not trivia; they are your map.\n\n[JAMIE]\nWhere do you want a learner to place their attention here?\n\n[ALEX]\nThe teaching point here is not the label; it is the move. Use aria-live=\"assertive\" only for urgent interruptions (errors). That is the difference between guessing and knowing: Use \"polite\" for non-urgent status updates.\n\n[PAUSE]\n\n[ALEX]\nBefore the learner moves on. This part earns its place because when expanded: set aria-expanded=\"true\" and remove the hidden attribute. That is the difference between following directions and owning the workflow.\n\n[JAMIE]\nGive me the version that sounds like an instructor, not a manual.\n\n[ALEX]\n7. How Standards Apply to GitHub Contributions: When you contribute to an open source project on GitHub, you will encounter accessibility in several contexts.\n\n[ALEX]\nNow slow down for the part people usually miss. Here is the learner-facing version. Reference the specific WCAG criterion. Put another way, bad: \"The button isn't accessible.\" Good: \"The 'Subscribe' button has no visible focus indicator, failing WCAG 2.4.7 Focus Visible (Level AA).\n\n[PAUSE]\n\n[JAMIE]\nIf I am listening before the workshop starts, what should settle in my mind first?\n\n[ALEX]\nThis is the move inside Reviewing a PR for Accessibility: checklist for any PR that touches HTML or UI.\n\n[ALEX]\nThese are the pieces that turn the idea into a usable move. Do new images have alt attributes? Do new interactive elements work with keyboard only? Do new form fields have associated elements? Are any new color-only indicators present? Does new dynamic content use aria-live if it updates without a page load?\n\n[JAMIE]\nThat is the kind of detail that keeps a screen reader user oriented.\n\n[ALEX]\nYes. The named thing - the heading, tab, field, branch, or button - is the handhold.\n\n[ALEX]\nHere is the moment where the page starts to make sense. Anchor this part on Writing Accessible Documentation. Documentation in Markdown is converted to HTML. The durable skill is not memorizing one screen. It is knowing how to find your footing when the screen changes.\n\n[ALEX]\nListen for the small confirmations in this list. Use heading levels in order (don't skip from H1 to H3). Write descriptive link text (not \"click here\"). Add alt text to images. Use actual lists (- or 1.) rather than faking them with symbols.\n\n[JAMIE]\nWhat is the ordered workflow?\n\n[ALEX]\nManual Testing (catches the rest) has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThe path is straightforward once it is named. Step one is keyboard-only navigation - unplug your mouse; can you do everything? Step two is screen reader walkthrough - navigate the feature with NVDA, JAWS, or VoiceOver. Step three is 200% zoom - does content reflow without horizontal scrolling? Step four is high contrast mode - Windows High Contrast or macOS Increase Contrast; are all elements still visible? The sequence works because every action has a confirmation.\n\n[JAMIE]\nGive me the sequence, because order matters here.\n\n[ALEX]\nFirst, disable CSS - does the content still make sense in reading order? Keep it that plain: know where you are, make the move, check the result.\n\n[PAUSE]\n\n[ALEX]\nThe next point gives the learner a handle. Learning Cards: Testing Against Standards has three jobs: name the idea, give the learner a move, and show what counts as evidence.\n\n[ALEX]\nThis is where the lesson becomes something you can check. You are the manual test -- automated tools catch only 30-40% of issues; your screen reader walkthrough catches the rest. Install the axe DevTools browser extension (Section 8 table) and run it on any page; results are announced as a list of violations with WCAG criterion references. When doing a keyboard-only navigation test, press Tab repeatedly and listen -- every interactive element should announce its name and role. The 200% zoom test (item 3) mirrors your daily experience -- if content breaks at 200%, file a bug citing WCAG 1.4.4 Resize Text. Windows High Contrast mode test (item 4) is one click: Settings, Accessibility, Contrast themes -- switch and check that all UI elements remain visible. The WAVE browser extension overlays icons on the page showing errors and warnings -- zoom in to read the small annotation labels.\n\n[JAMIE]\nLet's pause on 10. Official References. What should a learner take away from it?\n\n[ALEX]\nIf the interface shifts, 10. Official References is still useful because next: Appendix N: Advanced Search Back: Appendix L: Agents Reference Teaching chapter: Chapter 08: Open Source Culture.\n\n[PAUSE]\n\n[JAMIE]\nWhat should people carry with them after this?\n\n[ALEX]\nCarry the map. Know what page or tool you are in, know which action you are taking, and know what confirmation should follow. If the confirmation is missing, pause. That pause is not wasted time; it is professional judgment.\n\n[JAMIE]\nThat is a better way to say it than just follow the steps.\n\n[ALEX]\nRight. Steps matter, but understanding wins. That is episode 20. Next in the series is episode 21, where we keep building the same contributor muscles.\n", + "chapterPlanText": "{\n \"version\": 1,\n \"slug\": \"ep20-accessibility-standards\",\n \"chapters\": [\n {\n \"title\": \"Opening\",\n \"startSegmentIndex\": 0\n },\n {\n \"title\": \"WCAG, ARIA, and What They Mean for Your Contributions\",\n \"startSegmentIndex\": 7\n },\n {\n \"title\": \"1. WCAG 2.2 - The Four Principles\",\n \"startSegmentIndex\": 9\n },\n {\n \"title\": \"2. Conformance Levels: A, AA, AAA\",\n \"startSegmentIndex\": 16\n },\n {\n \"title\": \"3. Key Success Criteria for Web Contributions\",\n \"startSegmentIndex\": 17\n },\n {\n \"title\": \"4. ARIA - Roles, States, and Properties\",\n \"startSegmentIndex\": 19\n },\n {\n \"title\": \"5. ARIA Landmark Roles\",\n \"startSegmentIndex\": 24\n },\n {\n \"title\": \"7. How Standards Apply to GitHub Contributions\",\n \"startSegmentIndex\": 31\n },\n {\n \"title\": \"10. Official References\",\n \"startSegmentIndex\": 50\n },\n {\n \"title\": \"Closing Takeaways\",\n \"startSegmentIndex\": 53\n }\n ]\n}\n", + "sourceFiles": [ + { + "path": "S:\\code\\git-going-with-github\\docs\\appendix-m-accessibility-standards.md", + "headings": [ + { + "level": 2, + "title": "WCAG, ARIA, and What They Mean for Your Contributions" + }, + { + "level": 2, + "title": "Table of Contents" + }, + { + "level": 2, + "title": "1. WCAG 2.2 - The Four Principles" + }, + { + "level": 3, + "title": "Learning Cards: WCAG Overview" + }, + { + "level": 2, + "title": "2. Conformance Levels: A, AA, AAA" + }, + { + "level": 2, + "title": "3. Key Success Criteria for Web Contributions" + }, + { + "level": 3, + "title": "Perceivable" + }, + { + "level": 3, + "title": "Operable" + }, + { + "level": 3, + "title": "Understandable" + }, + { + "level": 3, + "title": "Robust" + }, + { + "level": 2, + "title": "4. ARIA - Roles, States, and Properties" + }, + { + "level": 3, + "title": "Three categories" + }, + { + "level": 3, + "title": "Important rules" + }, + { + "level": 2, + "title": "5. ARIA Landmark Roles" + }, + { + "level": 2, + "title": "6. Common ARIA Patterns" + }, + { + "level": 3, + "title": "Accessible Button (when `\r\n\r\n```\r\n\r\nWhen expanded: set `aria-expanded=\"true\"` and remove the `hidden` attribute.\r\n\r\n\r\n## 7. How Standards Apply to GitHub Contributions\r\n\r\nWhen you contribute to an open source project on GitHub, you will encounter accessibility in several contexts:\r\n\r\n### Filing an Accessibility Bug\r\n\r\nReference the specific WCAG criterion. This makes the bug actionable:\r\n\r\n> **Bad:** \"The button isn't accessible.\" \r\n> **Good:** \"The 'Subscribe' button has no visible focus indicator, failing WCAG 2.4.7 Focus Visible (Level AA). When navigating by keyboard, there is no visual indication of where focus is.\"\r\n\r\n### Reviewing a PR for Accessibility\r\n\r\nChecklist for any PR that touches HTML or UI:\r\n\r\n- Do new images have `alt` attributes?\r\n- Do new interactive elements work with keyboard only?\r\n- Do new form fields have associated `