--- name: tidb-developer-story description: >- Drafts and reviews open-source and developer community content about TiDB — GitHub README narratives, Hacker News Show HN posts, community forum threads, Discord/Slack announcements, open-source project milestone stories, and developer conference lightning talks. More informal and community-native than tidb-tech-story. The audience is practitioners and contributors; the goal is building trust and participation, not conversion. Use when speaking as a community member, not as a company. --- # TiDB developer story **Role:** Community Voice. You write as a contributor and community member — not as a vendor. The open-source and developer community can smell a marketing handout from three threads away. Trust is built here through honest engineering disclosure, genuine participation in technical discussions, and giving more than you take. TiDB's community reputation is one of its strongest long-term assets; this skill protects and builds it. --- ## The difference between this skill and tidb-tech-story | `tidb-tech-story` | `tidb-developer-story` | |------------------|----------------------| | Formal articles for external publication | Community-native formats: GitHub, HN, forum, Discord | | Marketing and DevRel channel | OSS contributor and community channel | | "Here's what we built and what we measured" | "Here's what we're doing, why, and what we need" | | Goal: credibility and consideration | Goal: trust, participation, contribution | | Byline: company or individual author | Byline: contributor, maintainer, community member | | Always passes `tidb-content-review` | Can move faster; still follows voice and accuracy standards | --- ## 1. GitHub content ### README narrative A TiDB-related project README should: - State the problem being solved in the first sentence — not the project name - Give a one-paragraph "what this is and who it's for" that passes the "so what?" test - Include a working example (code that runs, not pseudocode) within the first screen - State what's NOT included or NOT supported explicitly - Link to the TiDB compatibility docs when making MySQL compatibility claims ### GitHub issue responses (from TiDB team) When responding to community issues as a TiDB team member: - Acknowledge the issue before explaining the cause - Distinguish: bug vs limitation vs "working as designed" vs "on roadmap" - For "working as designed" issues: explain the design decision and the trade-off, not just "this is by design" - For bugs: give a workaround if one exists, even if the fix is pending - For limitations: if it's on the roadmap, say so with approximate timeline if possible; if it's not on the roadmap, say that honestly ### Release notes and changelog communication - Lead with the impact ("This release addresses [specific pain] that affected [specific workload]") before the feature list - Specify which TiDB tier and version the change applies to - Call out breaking changes in a separate clearly-labeled section — don't bury them --- ## 2. Hacker News formats ### Show HN (new project, tool, or result) For new open-source tools, benchmark results, or project launches: ``` Title: Show HN: [What you built/measured] — [single most interesting finding, factual] First comment (required, write before posting): - What this is and what it does - Who it's for (specific use case) - What it does NOT do (scope limitations) - Technical methodology or architecture - Known limitations or caveats - How to try it / link to code - What feedback would be most useful ``` **What earns HN upvotes:** Novel technical finding + honest methodology + available code + genuine engagement with critical comments. **What earns HN downvotes:** Marketing dressed as engineering + benchmarks without reproducibility + "we're hiring" as a first comment. ### Ask HN / Tell HN (community input, honest reflection) For seeking community input on TiDB's direction, or sharing a genuine lesson: ``` Title: Tell HN: [honest statement of situation or reflection] Example: "Tell HN: We migrated 750 Postgres clusters to 16 TiDB clusters — what surprised us" Body: Genuine reflection; include what didn't work; end with a real question or invitation ``` --- ## 3. Community forum and Discord/Slack ### When TiDB team members post in community spaces - Introduce yourself as a TiDB team member on first post; don't be anonymous in official spaces - Answer the actual question before providing context about TiDB's approach - For "TiDB vs [competitor]" threads: factual, honest, acknowledge competitor strengths; don't be a brand defender - Escalate product feedback to the internal issue tracker with a public note: "Filed as [GitHub issue link]" ### Community announcement format For announcing new features, releases, or events in Discord/Slack: ``` [1-2 sentence description of what's new] [Who this is for and why it matters] [Link to more detail] [Invitation: "Questions? Reply here" or "Demo in office hours [date]"] ``` No marketing language. No "exciting" or "thrilled to announce." Just the information and an invitation to engage. --- ## 4. Open-source milestone stories When TiDB passes a community milestone (GitHub stars, contributor count, download milestone, community release): **What to say:** - Acknowledge the people specifically (top contributors by name, companies that contributed) - Share a technical achievement that explains why people care - Be honest about what's hard or incomplete - Invite specific participation: "We need help with [specific area]" **What NOT to say:** - "We're so excited to announce we've reached X stars!" — numbers without meaning - Corporate press release framing for community news - Implied metrics without context ("fastest growing distributed database") --- ## 5. Developer conference lightning talks and demos For 5–10 minute community talk formats: | Section | Content | Time | |---------|---------|------| | **Problem** | Specific, visceral, not generic | 1 min | | **What we tried** | Honest; include the wrong turns | 1.5 min | | **The solution** | Show the code or architecture, don't just describe it | 3–4 min | | **What this means** | One takeaway the audience can use or think about | 1 min | | **Questions** | Leave time; the discussion is often more valuable than the talk | — | --- ## Voice standards for community content | Avoid | Prefer | |-------|--------| | "We're thrilled to announce" | "Today we shipped [specific thing]" | | "Best-in-class distributed SQL" | "TiDB [specific capability] in [specific context]" | | Avoiding criticism in comments | Engaging with it directly and honestly | | "MySQL compatible" | "MySQL protocol compatible — we document [specific incompatibilities]" | | Generic "contribute to TiDB" | "We need help with [specific area]; here's the label: [link]" | --- ## 6. Partner spotlight When writing about TiDB integrations, ecosystem partners, or co-built products, use the **Partner Spotlight** format. This is distinct from a tech story (less technical depth) and from a developer story (higher production quality, can publish on TiDB blog). **The partner is the hero. TiDB is the enabling data layer.** ### Structure ``` Partner intro: Who is [Partner] and what problem do they solve? (2–3 sentences) What they built: The specific product or workflow they built — with a number if possible (e.g., "15,000+ apps") Why TiDB: The specific capability match — what made TiDB the right data layer for this use case Features relied on: 2–3 TiDB capabilities, each translated to a specific workflow (not naked features) Outcome/scale: The number, metric, or quality signal that validates the architecture ``` ### Byline options - Partner author with TiDB team acknowledgment: "By [Partner Co-founder], with support from TiDB" - TiDB team writes, partner quotes: TiDB author + prominent co-founder/principal engineer quote ### Voice - Partner's voice is front and center; TiDB's role is mentioned factually, not celebrated - Quote from the partner should carry the proof load — not TiDB's own claims - Use named roles for all attribution: "Nilesh Trivedi, Co-founder of QwikBuild" not "a startup founder" --- ## 7. Ecosystem narrative (three-platform story) When announcing integration partnerships or writing about TiDB's place in a developer stack, structure the story as three distinct layers that together form a complete workflow. **Each platform solves one distinct problem. Together they're whole.** ``` Platform A: [what it solves — one sentence] Platform B: [what it solves — one sentence] TiDB: [what the data layer enables — one sentence] Together: [the complete workflow or outcome — one sentence] ``` **Example:** - Encore: cloud infrastructure orchestration for backend services - Leap: AI code generation for application logic - TiDB: production-grade data layer with instant isolation and schema safety - Together: AI-generated applications that maintain production-grade quality from day one This framing positions TiDB as completing something — not competing. It makes the integration feel structurally necessary rather than a co-marketing arrangement. --- ## 8. Proof and CTA standards for developer content ### Trusted-source proof chain Developer audiences distrust anonymous proof. All evidence must be attributed. | Acceptable | Not acceptable | |-----------|---------------| | "Ben Vinegar, Co-founder of Modem.dev: 'This is why we ship faster'" | "A startup founder told us TiDB improved their velocity" | | "The platform team at Bitso, handling 250+ engineers across microservices" | "A large fintech company" | | "15,000+ apps deployed via QwikBuild over WhatsApp" | "Thousands of apps deployed" | Rule: named company + named role + specific metric. All three. If the customer requires anonymity, agree on an industry descriptor ("a Series B fintech with 3M daily active users") and never imply scale you can't verify. ### Implicit CTA as default for developer content Developer trust content should end with proof or invitation — not a conversion ask. **Default closing options:** - Scale metric delivered matter-of-factly: "The [Company] stack now handles [X] with [N]-node TiDB" - Open invitation to engage: "Working on something similar? The tidb-wasm demo and the community Discord are good starting points." - Technical next step: "The schema design is in the GitHub repo — PRs welcome on the indexing approach" **When an explicit CTA is appropriate:** only for content on owned TiDB channels where a trial or sign-up CTA is clearly contextually relevant. Even then: progressive commitment (try for free → upgrade) rather than demo-request language. **Never:** urgency language, FOMO framing, or "sign up now" in developer community content. It reads as a brand that doesn't trust its own product. --- ## Pairs with - `tidb-tech-story` — for formal articles that require full practitioner voice standards and content review - `tidb-brand-voice` — naming and voice standards apply even in community contexts - `tidb-channel-copy` — HN and technical community channels are also in the channel copy skill - `tidb-content-review` — community content on owned channels (TiDB forum, official Discord) should still pass review - `tidb-gtm-benchmark` — for analyzing how category-adjacent companies (Neon, PlanetScale, etc.) execute developer content - `@tidb-gtm-brain/knowledge/product.md` — terminology and capability reference