|
| 1 | +# Overview |
| 2 | + |
| 3 | +GitHub Well‑Architected is expanding quickly—new products, new adoption patterns, and rising expectations for clear, practical, and secure guidance. To keep pace, **we’re inviting our GitHub Partners to help define the guidance that becomes the global standard.** |
| 4 | + |
| 5 | +Partners bring something uniquely powerful: **you see what truly works** across industries, architectures, constraints, and delivery context. Your real‑world experience turns Well‑Architected from “good guidance” into **trusted, repeatable, field‑proven practice.** |
| 6 | + |
| 7 | +This repository is your space to propose, author, and refine high‑impact content alongside GitHub SMEs and the broader community. Our goal is simple: **make contributing easy, make your impact visible, and help every customer succeed.** |
| 8 | + |
| 9 | +## 🌟 Why we are here |
| 10 | + |
| 11 | +Partner contributions elevate Well‑Architected in ways only you can: |
| 12 | + |
| 13 | +- **Partners understand reality:** constraints, politics, outages, risk decisions, last‑minute pivots — the pressure points that shape real delivery outcomes. |
| 14 | +- **This space enables collaboration:** a shared home for partners, GitHub SMEs and broader community to build design‑thinking‑led best practices. |
| 15 | +- **Intentional matters:** in times of rapid change, sharing intent and building on one another helps everyone move faster on the knowns while exploring the unknowns with confidence. |
| 16 | + |
| 17 | +## 🛠️ Where you can contribute |
| 18 | + |
| 19 | +The most impactful areas for partner contributions include: |
| 20 | + |
| 21 | +### 1️⃣ Real‑world patterns and decision guidance |
| 22 | + |
| 23 | +- Reference patterns, tradeoffs, and common anti‑patterns observed across industries |
| 24 | +- “What does a good GitHub platform setup look like for an organization like mine?” |
| 25 | +- Example topics: context engineering, managing polyrepos at scale, GitHub governance patterns |
| 26 | + |
| 27 | +### 2️⃣ Implementation‑ready playbooks |
| 28 | + |
| 29 | +- Step‑by‑step guides, rollout sequencing, and operational readiness patterns |
| 30 | +- “How do we roll this out safely and successfully across our teams?” |
| 31 | +- Example topics: pilot‑to‑production playbooks, CI/CD adoption blueprints, automation and monitoring standards |
| 32 | + |
| 33 | +### 3️⃣ Enterprise risk and compliance‑informed guidance |
| 34 | + |
| 35 | +- Managing threat, audit, and compliance requirements using secure‑by‑default GitHub practices |
| 36 | +- “What will security reviewers ask, and how do we prepare for it?” |
| 37 | +- Example topics: security in agentic workflows, secure defaults, compliance‑ready configurations |
| 38 | + |
| 39 | +### 4️⃣ Lessons learned |
| 40 | + |
| 41 | +- Real‑world breakdowns, pivots, constraints, and pitfalls to avoid |
| 42 | +- “What should we watch out for so we don’t repeat common mistakes?” |
| 43 | +- Example topics: scaling challenges, workarounds for legacy constraints |
| 44 | + |
| 45 | +### 5️⃣ Content quality improvement |
| 46 | + |
| 47 | +- Enhancing clarity, readability, terminology, diagrams, and discoverability |
| 48 | +- “Can you make this easier to understand, adopt, and reference?” |
| 49 | +- Examples: consistent terminology, improved diagrams, cross‑referenced guidance |
| 50 | + |
| 51 | +## ✅ What “good” looks like |
| 52 | + |
| 53 | +We’re not chasing volume — we’re building **future‑ready guidance** that customers and field teams can trust. |
| 54 | + |
| 55 | +Great content is: |
| 56 | + |
| 57 | +- **Actionable:** clear steps, checklists, examples |
| 58 | +- **Explicit:** tradeoffs and assumptions clearly stated |
| 59 | +- **Responsible AI–aligned** |
| 60 | +- **Secure by default** |
| 61 | +- **Designed for GitHub users:** practical, grounded, and real-world usage |
| 62 | + |
| 63 | +## 🏁 Getting started |
| 64 | + |
| 65 | +Step 1: Use [Create a content request Issue] to propose your idea. Include: |
| 66 | + |
| 67 | +- The problem you’re solving |
| 68 | +- The intended audience |
| 69 | +- Your recommended approach |
| 70 | +- Supporting context (patterns, constraints, anonymized examples) |
| 71 | + |
| 72 | +Step 2: Follow the contribution workflow in [CONTRIBUTING] |
| 73 | + |
| 74 | +Step 3: Keep your Technical Partner Manager informed! |
| 75 | + |
| 76 | +### How contributions move |
| 77 | + |
| 78 | +A contribution moves through four simple states: |
| 79 | + |
| 80 | +```mermaid |
| 81 | +--- |
| 82 | +config: |
| 83 | + htmlLabels: true |
| 84 | +--- |
| 85 | +flowchart LR |
| 86 | + PROPOSED[" |
| 87 | + **PROPOSED** |
| 88 | + <div style='text-align: left;'> |
| 89 | + 🟢 Partner |
| 90 | + 🔵 Tech. Partner Manager |
| 91 | + </div> |
| 92 | + "] |
| 93 | +
|
| 94 | + WIP[" |
| 95 | + **In PROGRESS** |
| 96 | + <div style='text-align: left;'> |
| 97 | + 🟢 Partner |
| 98 | + 🟡 Community Collaborators |
| 99 | + </div> |
| 100 | + "] |
| 101 | +
|
| 102 | + REVIEW[" |
| 103 | + **REVIEW** |
| 104 | + <div style='text-align: left;'> |
| 105 | + 🔵 GitHub SMEs |
| 106 | + 🔵 Tech. Partner Manager |
| 107 | + </div> |
| 108 | + "] |
| 109 | +
|
| 110 | + PUBLISHED[" |
| 111 | + **PUBLISHED** |
| 112 | + <div style='text-align: left;'> |
| 113 | + 🔵 WAF Maintainer |
| 114 | + |
| 115 | + </div> |
| 116 | + "] |
| 117 | +
|
| 118 | + PROPOSED --> WIP |
| 119 | + WIP --> REVIEW |
| 120 | + REVIEW --> PUBLISHED |
| 121 | +
|
| 122 | + linkStyle default stroke-width:6px; |
| 123 | +``` |
| 124 | + |
| 125 | +### At a glance (state → owner → responsibility) |
| 126 | + |
| 127 | +- **PROPOSED** → **Partner**, **Technical Partner Manager**: Submit an idea; scope it, avoid duplication, and connect to the right collaborators. |
| 128 | +- **IN PROGRESS** → **Partner**, **Community Collaborators**: Draft content; collaborators suggest improvements and examples. |
| 129 | +- **REVIEW** → **GitHub SMEs**, **Technical Partner Manager**: Review, request changes, and approve; keep the review moving. |
| 130 | +- **PUBLISHED** → **GitHub**: Merge and publish to the site; confirm attribution and notify the author. |
| 131 | + |
| 132 | +## 📣 Communication & update cadence |
| 133 | + |
| 134 | +| Type | Frequency | Channel | Content | |
| 135 | +|-------------|-----------|----------|---------| |
| 136 | +| Partners Newsletter | Monthly | Email | Spotlights, what shipped, what's next | |
| 137 | +| Tech Forum | Monthly | Live online| Recognitions, priority themes, content request backlog | |
| 138 | +| Feedback & Questions | Ad hoc | [GitHub Discussions] | Feedback, suggestions, comments, questions | |
| 139 | + |
| 140 | +## 🎉 How we celebrate contributions |
| 141 | + |
| 142 | +Your impact is visible and celebrated through: |
| 143 | + |
| 144 | +- Spotlight in monthly partner newsletters |
| 145 | +- Monthly tech forum callouts |
| 146 | +- Recognition at partner events |
| 147 | +- Author attribution on our site (company slug + user handle) |
| 148 | + |
| 149 | +## 🔗 Quick resource links |
| 150 | + |
| 151 | +- [Create a content request Issue] - 🏁 Start here! |
| 152 | +- [CONTRIBUTING] - How we collaborate |
| 153 | +- [GitHub Well‑Architected Framework Overview] - Our mission, pillars, principles |
| 154 | +- [Partners Portal] |
| 155 | +- [GitHub Discussions] |
| 156 | + |
| 157 | +## 🚀 Call‑to‑Action |
| 158 | + |
| 159 | +If you're ready to help shape how customers design, secure, and scale GitHub, **start by submitting a content proposal. Your experience doesn’t just help customers — it shapes the global standard for GitHub excellence.** |
| 160 | + |
| 161 | +[CONTRIBUTING]: ../CONTRIBUTING.md |
| 162 | +[Create a content request Issue]: https://github.com/github/github-well-architected/issues/new?assignees=&labels=content-request&template=request-content.yml |
| 163 | +[GitHub Discussions]: https://github.com/githubpartners-community/community/discussions/categories/waf-feedback-and-suggestions |
| 164 | +[GitHub Well‑Architected Framework Overview]: ./framework-overview.md |
| 165 | +[Partners Portal]: https://portal.github.partners/#/page/well-architected |
0 commit comments