GSoC Proposal Wisdom

This generates:

• references/generated/manifest.json
• references/generated/corpus_data.json
• references/generated/patterns.json
• references/generated/scores.json
• references/generated/analysis_prompts.md

3. Research the target project before drafting

Run:

scripts/06_research_project.py \
  --repo-path /path/to/local/repo \
  --github owner/repo \
  --user applicant-github-login

This generates a repo-aware brief under:

• references/generated/project_research/<slug>.json
• references/generated/project_research/<slug>.md

What this research should cover:

• local codebase structure, stack, tooling, tests, and docs
• recent local git activity when available
• GitHub issues and pull requests from the applicant
• GitHub issues and pull requests from maintainers
• GitHub issues and pull requests from other contributors
• active labels, recurring themes, and candidate proposal angles

4. Load only the references you need

• Always read references/gsoc_wisdom.md.
• Read references/project_intelligence.md when you need repo/GitHub research guidance.
• Read references/generated/patterns.json when you need prevalence, baselines, or scoring weights.
• Read references/generated/analysis_prompts.md when you need scaffolding prompts for drafting, critique, or timeline generation.
• Read references/generated/scores.json when you want examples of stronger and weaker structures inside the corpus.
• Read references/generated/corpus_data.json only when you need document-level features or section inventories.
• Read the generated references/generated/project_research/<slug>.md brief for the target project before writing motivation, scope, deliverables, or timeline.

5. Build the proposal around evidence-backed sections

Default blueprint:

1. Title and project snapshot
2. Abstract or executive summary
3. Motivation and fit for the organization
4. Problem statement and current gap
5. Proposed approach
6. Deliverables and success criteria
7. Relevant experience and prior contributions
8. Testing, documentation, and communication plan
9. Timeline with weeks or phases
10. Availability, timezone, and other commitments
11. Post-program continuation plan

If the organization has its own template, preserve the required headings but still inject the corpus-derived signals above.

Use project research to strengthen:

• motivation: cite real subsystems, issues, specs, or maintainers
• deliverables: tie them to concrete gaps visible in the repo and issue tracker
• credibility: cite prior applicant PRs, codebase study, prototypes, or issue discussions
• timeline: map milestones onto actual project boundaries and reviewable artifacts

6. Revise against the scorer before finalizing

Run:

scripts/04_score_proposals.py \
  --patterns references/generated/patterns.json \
  --input /path/to/draft.md

Use the output to patch missing sections, weak evidence, vague deliverables, or an under-specified timeline.

Drafting Rules

• Lead with the project's problem and proposed outcomes, not autobiography.
• Ground motivation in the actual organization, codebase, mentors, specs, issues, or prior contributions.
• Turn goals into shippable deliverables with observable outputs.
• Prefer week-by-week milestones when the project is implementation-heavy; use phases when discovery dominates the early schedule.
• Include testing, documentation, communication cadence, and fallback thinking as feasibility signals.
• Be cautious with overconfident claims. Promise concrete increments, not sweeping rewrites.
• When the corpus lacks negative examples, phrase warnings as heuristics rather than hard rules.

Script Guide

• scripts/01_walk_corpus.py: index markdown, text, and PDF proposals in a corpus directory.
• scripts/02_extract_structure.py: extract headings, section signals, timelines, links, and proposal features.
• scripts/03_mine_patterns.py: aggregate corpus-wide baselines and scoring guidance.
• scripts/04_score_proposals.py: score a corpus or a single draft against the distilled heuristics.
• scripts/05_prepare_prompts.py: generate reusable prompt scaffolds from the mined patterns.
• scripts/06_research_project.py: inspect a local repo plus GitHub activity and generate a proposal-ready project brief.
• scripts/run_pipeline.py: run the full pipeline in order.

Failure Modes

• If the corpus is mostly accepted proposals, avoid pretending you can identify rejection causes with confidence.
• If a draft lacks prior contributions, compensate with specific codebase study, issue references, prototypes, or a narrower scope.
• If the project brief is vague, spend effort clarifying deliverables and interfaces before polishing prose.
• If a proposal template is rigid, optimize within the template instead of forcing new headings.
• If the GitHub tracker is large, prefer recent, maintainer-touched, and label-rich issues over trying to reason about every ticket equally.