[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"sanity-Ri7UvPS0MVSV07Atp0haJG6yZXRQL8M_3ybONi0-gcA":3,"sanity-GjkLzMHzbZBEBZaF-hmmrO3rzu0-SaP1PuJ7jyLGQqI":539},{"data":4,"sourceMap":-1},{"latestPodcast":5,"latestReleases":14,"post":39,"recent":514},[6],{"_id":7,"publishedAt":8,"slug":9,"sponsored":12,"title":13},"50f4509c-4f55-4f11-8adc-5556e821ea77","2026-06-30T07:40:00.000Z",{"_type":10,"current":11},"slug","why-intent-prediction-needs-more-than-an-llm",null,"Why intent prediction needs more than an LLM",[15,21,27,33],{"_id":16,"publishedAt":17,"slug":18,"title":20},"eb5b66eb-9410-4329-83bb-22bbff39402a","2026-04-28T13:00:00.000Z",{"_type":10,"current":19},"turn-scattered-knowledge-into-trusted-intelligence","Turning scattered knowledge into trusted intelligence: Stack Internal 2026.3",{"_id":22,"publishedAt":23,"slug":24,"title":26},"369c2401-b62e-4a37-8ff8-bf603023ecad","2026-03-02T15:03:00.988Z",{"_type":10,"current":25},"what-s-new-at-stack-overflow-march-2026","What’s new at Stack Overflow: March 2026",{"_id":28,"publishedAt":29,"slug":30,"title":32},"5e9053a4-07ea-447c-91ea-29e0b6228537","2026-02-02T15:00:00.000Z",{"_type":10,"current":31},"what-s-new-at-stack-overflow-february-2026","What’s new at Stack Overflow: February 2026",{"_id":34,"publishedAt":35,"slug":36,"title":38},"a1b538eb-a8a6-46d0-80a1-ac70ec9bb935","2026-01-05T10:00:00.000-05:00",{"_type":10,"current":37},"what-s-new-at-stack-overflow-january-2026","What’s new at Stack Overflow: January 2026",{"_createdAt":40,"_id":41,"_rev":42,"_system":43,"_type":46,"_updatedAt":47,"author":48,"body":73,"comments":476,"dateUrl":477,"excerpt":478,"image":479,"legacyBody":482,"product":12,"publishedAt":485,"slug":486,"sponsored":12,"tags":488,"title":513,"visible":476},"2023-05-24T12:51:00Z","wp-post-20027","MeHyIAvvHesTDJfyOOZ3Fw",{"base":44},{"id":41,"rev":45},"LIB4H7UiOBRX1pcyrgi2xu","blogPost","2026-05-18T19:48:06Z",[49,65],{"_createdAt":50,"_id":51,"_rev":52,"_type":53,"_updatedAt":54,"avatar":55,"bio":60,"employee":61,"name":62,"slug":63},"2023-05-23T16:27:18Z","wp-author-cap-20030","dgl3SCUzppW3U2LvCoP6c0","blogAuthor","2023-06-20T15:05:12Z",{"_type":56,"asset":57},"image",{"_ref":58,"_type":59},"image-82661155abcc195ea39900791ea7ac67a41723e1-40x40-png","reference","","none","Jared Bhatti",{"current":64},"jared-bhatti",{"_createdAt":50,"_id":66,"_rev":52,"_type":53,"_updatedAt":54,"avatar":67,"bio":60,"employee":61,"name":70,"slug":71},"wp-author-cap-20032",{"_type":56,"asset":68},{"_ref":69,"_type":59},"image-dd669b8eba7319e9ac91cb3d2883956e2007120a-400x400-jpg","Zachary Sarah Corleissen",{"current":72},"zachary-sarah-corleissen",[74,85,93,113,122,130,140,148,156,164,172,189,197,205,213,227,239,251,259,278,286,305,317,340,374,386,398,426,434,442,450,458],{"_key":75,"_type":76,"children":77,"markDefs":83,"style":84},"68f55d01d703","block",[78],{"_key":79,"_type":80,"marks":81,"text":82},"68f55d01d7030","span",[],"It’s exciting for open projects to grow from a handful of users to a team of collaborators working on and using the software. Moving from one to many contributors is a powerful moment for any project. However, as a project scales and grows, one area is frequently neglected: the documentation.",[],"normal",{"_key":86,"_type":76,"children":87,"markDefs":92,"style":84},"5c5447ff0a3f",[88],{"_key":89,"_type":80,"marks":90,"text":91},"5c5447ff0a3f0",[],"Missing or insufficient documentation hinders a project’s ability to scale. Most potential users skim your documentation first to see if it fits their needs and to judge how difficult it might be to use. Documentation makes your project’s first impression: not only on potential users, but also on potential contributors.",[],{"_key":94,"_type":76,"children":95,"markDefs":109,"style":84},"262ceee0890c",[96,100,105],{"_key":97,"_type":80,"marks":98,"text":99},"262ceee0890c0",[],"Writing and improving documentation offers a clear path for people to contribute to your project—provided you offer the right guidance and processes to support them. This article covers best practices for attracting and retaining open-source documentation contributors based on our experience building and managing documentation for ",{"_key":101,"_type":80,"marks":102,"text":104},"262ceee0890c1",[103],"eb7cc5eb6224","Kubernetes",{"_key":106,"_type":80,"marks":107,"text":108},"262ceee0890c2",[],".",[110],{"_key":103,"_type":111,"href":112,"reference":12},"link","https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fhome\u002F",{"_key":114,"_type":76,"children":115,"markDefs":120,"style":121},"f66d022adfea",[116],{"_key":117,"_type":80,"marks":118,"text":119},"f66d022adfea0",[],"Evaluate your existing docs",[],"h2",{"_key":123,"_type":76,"children":124,"markDefs":129,"style":84},"98594ae5fb1b",[125],{"_key":126,"_type":80,"marks":127,"text":128},"98594ae5fb1b0",[],"Begin by evaluating your existing documentation. You can’t ask for help from your contributors if you don’t know what you need! As you evaluate your documentation, consider it from the perspective of your users:",[],{"_key":131,"_type":76,"children":132,"level":137,"listItem":138,"markDefs":139,"style":84},"ff4135558977",[133],{"_key":134,"_type":80,"marks":135,"text":136},"ff41355589770",[],"What are my users’ needs? Do these docs meet their needs?",1,"bullet",[],{"_key":141,"_type":76,"children":142,"level":137,"listItem":138,"markDefs":147,"style":84},"67eee4179538",[143],{"_key":144,"_type":80,"marks":145,"text":146},"67eee41795380",[],"Are there any features that are undocumented? Is critical information missing? Are there other content gaps to fill?",[],{"_key":149,"_type":76,"children":150,"level":137,"listItem":138,"markDefs":155,"style":84},"2038454568ca",[151],{"_key":152,"_type":80,"marks":153,"text":154},"2038454568ca0",[],"What content is outdated and needs to be deleted?",[],{"_key":157,"_type":76,"children":158,"level":137,"listItem":138,"markDefs":163,"style":84},"7566b23599b8",[159],{"_key":160,"_type":80,"marks":161,"text":162},"7566b23599b80",[],"What content needs to be refactored and clarified?",[],{"_key":165,"_type":76,"children":166,"markDefs":171,"style":84},"22be8f4ba9bb",[167],{"_key":168,"_type":80,"marks":169,"text":170},"22be8f4ba9bb0",[],"Don’t get bogged down trying to fix each issue you come across. Instead, open an issue for each problem you encounter.",[],{"_key":173,"_type":76,"children":174,"markDefs":188,"style":84},"4fc83b0c3646",[175,179,184],{"_key":176,"_type":80,"marks":177,"text":178},"4fc83b0c36460",[],"Once you’ve evaluated your content, review the issues you opened and determine whether you need to fix any issues ",{"_key":180,"_type":80,"marks":181,"text":183},"4fc83b0c36461",[182],"em","before",{"_key":185,"_type":80,"marks":186,"text":187},"4fc83b0c36462",[]," you invite contributors to address them. For example, if your documentation consists of a single-page `README.md` file with 2,500 lines, breaking it up into smaller individual documents will lower the barrier for contributors. If your documentation contains outdated content, delete it so that new contributors can join more easily. Fix any issues you think would block new contributors from working on your content.",[],{"_key":190,"_type":76,"children":191,"markDefs":196,"style":121},"59a212435d7d",[192],{"_key":193,"_type":80,"marks":194,"text":195},"59a212435d7d0",[],"Triage your doc issues",[],{"_key":198,"_type":76,"children":199,"markDefs":204,"style":84},"b5cf9d5f003e",[200],{"_key":201,"_type":80,"marks":202,"text":203},"b5cf9d5f003e0",[],"A simple doc issue triage process might look something like this:",[],{"_key":206,"_type":76,"children":207,"markDefs":212,"style":84},"192f569db74e",[208],{"_key":209,"_type":80,"marks":210,"text":211},"192f569db74e0",[],"Now that you have a set of issues related to your documentation, apply triage. Triaging documentation issues is similar to triaging code issues: make sure an issue is valid and actionable and assign a priority.",[],{"_key":214,"_type":76,"children":215,"level":137,"listItem":225,"markDefs":226,"style":84},"8013066b60b0",[216,221],{"_key":217,"_type":80,"marks":218,"text":220},"8013066b60b00",[219],"strong","Validate if the issue is related to your documentation and not related to your code: ",{"_key":222,"_type":80,"marks":223,"text":224},"8013066b60b01",[],"It’s common for an issue to be related to both. Consider whether new documentation or a code change would help your users more. For example, if a CLI command has a confusing name, you could either document the command better or rename the command to something clearer.","number",[],{"_key":228,"_type":76,"children":229,"level":137,"listItem":225,"markDefs":238,"style":84},"63115e45f956",[230,234],{"_key":231,"_type":80,"marks":232,"text":233},"63115e45f9560",[219],"Assess whether the issue is actionable:",{"_key":235,"_type":80,"marks":236,"text":237},"63115e45f9561",[]," Does the issue contain everything a contributor needs in order to fix the problem? Tag unclear issues with something like `needs more information` and follow up with the person who filed the issue. For example, an issue that reads only, “This didn’t work,” without specifying what didn’t work or how to fix it isn’t actionable.",[],{"_key":240,"_type":76,"children":241,"level":137,"listItem":225,"markDefs":250,"style":84},"d1e24b5b07a6",[242,246],{"_key":243,"_type":80,"marks":244,"text":245},"d1e24b5b07a60",[219],"Assign a priority to the issue:",{"_key":247,"_type":80,"marks":248,"text":249},"d1e24b5b07a61",[]," What does the project need to fix first? You can use a priority numbering system (like P0-P4) or specify your priorities with tags like `now`,`next`, and `backlog`.",[],{"_key":252,"_type":76,"children":253,"markDefs":258,"style":84},"e3daf0f7657b",[254],{"_key":255,"_type":80,"marks":256,"text":257},"e3daf0f7657b0",[],"Finally, for new contributors, tag issues that are quick fixes or good first issues. A label like `good first issue` makes it easy for new contributors to identify issues they can take on when they’re getting started with your project.",[],{"_key":260,"_type":76,"children":261,"markDefs":275,"style":84},"d91acd458e4e",[262,266,271],{"_key":263,"_type":80,"marks":264,"text":265},"d91acd458e4e0",[],"Kubernetes uses a ",{"_key":267,"_type":80,"marks":268,"text":270},"d91acd458e4e1",[269],"97ff4db4da6b","doc issue triage process",{"_key":272,"_type":80,"marks":273,"text":274},"d91acd458e4e2",[]," very similar to the one listed above.",[276],{"_key":269,"_type":111,"href":277,"reference":12},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fcontribute\u002Freview\u002Ffor-approvers\u002F#triage-and-categorize-issues",{"_key":279,"_type":76,"children":280,"markDefs":285,"style":121},"1e45ff7dbc79",[281],{"_key":282,"_type":80,"marks":283,"text":284},"1e45ff7dbc790",[],"Add documentation processes to your contributor guidelines",[],{"_key":287,"_type":76,"children":288,"markDefs":302,"style":84},"bb7f3f95f418",[289,293,298],{"_key":290,"_type":80,"marks":291,"text":292},"bb7f3f95f4180",[],"Hopefully, you already have contributor guidelines (if not, GitHub has ",{"_key":294,"_type":80,"marks":295,"text":297},"bb7f3f95f4181",[296],"81b9a6b4e24c","great guidance you can follow",{"_key":299,"_type":80,"marks":300,"text":301},"bb7f3f95f4182",[]," in setting them out). In your guidelines, include guidance specific to documentation, including:",[303],{"_key":296,"_type":111,"href":304,"reference":12},"https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcommunities\u002Fsetting-up-your-project-for-healthy-contributions\u002Fsetting-guidelines-for-repository-contributors",{"_key":306,"_type":76,"children":307,"level":137,"listItem":225,"markDefs":316,"style":84},"b755b8457374",[308,312],{"_key":309,"_type":80,"marks":310,"text":311},"b755b84573740",[219],"How documentation is written and served:",{"_key":313,"_type":80,"marks":314,"text":315},"b755b84573741",[]," Indicate which markup language(s) you’re using, any documentation templates you’re using, and whether you’re using any tools like static site generators to display your content.",[],{"_key":318,"_type":76,"children":319,"level":137,"listItem":225,"markDefs":337,"style":84},"79b0468ea1bc",[320,324,328,333],{"_key":321,"_type":80,"marks":322,"text":323},"79b0468ea1bc0",[219],"How documentation is organized:",{"_key":325,"_type":80,"marks":326,"text":327},"79b0468ea1bc1",[]," Give clear guidance on what types of content belong where, including how files and folders are organized. Specify which kinds of content belong in product documentation and what content might be better suited to ",{"_key":329,"_type":80,"marks":330,"text":332},"79b0468ea1bc2",[331],"96651e676525","Stack Overflow",{"_key":334,"_type":80,"marks":335,"text":336},"79b0468ea1bc3",[]," or your project’s blog.",[338],{"_key":331,"_type":111,"href":339,"reference":12},"https:\u002F\u002Fstackoverflow.com\u002F",{"_key":341,"_type":76,"children":342,"level":137,"listItem":225,"markDefs":369,"style":84},"2ab1643344d2",[343,347,351,356,360,365],{"_key":344,"_type":80,"marks":345,"text":346},"2ab1643344d20",[219],"Any documentation standards:",{"_key":348,"_type":80,"marks":349,"text":350},"2ab1643344d21",[]," Specify any naming conventions you’re using in your documentation. You can preempt a high volume of questions from your contributors about grammar, capitalization, and punctuation by following a public style guide. Both ",{"_key":352,"_type":80,"marks":353,"text":355},"2ab1643344d22",[354],"a8583d4dc618","Google",{"_key":357,"_type":80,"marks":358,"text":359},"2ab1643344d23",[]," and ",{"_key":361,"_type":80,"marks":362,"text":364},"2ab1643344d24",[363],"bb03ad7254f2","Microsoft",{"_key":366,"_type":80,"marks":367,"text":368},"2ab1643344d25",[]," provide public documentation style guides.",[370,372],{"_key":354,"_type":111,"href":371,"reference":12},"https:\u002F\u002Fdevelopers.google.com\u002Fstyle",{"_key":363,"_type":111,"href":373,"reference":12},"https:\u002F\u002Fdocs.microsoft.com\u002Fen-us\u002Fstyle-guide\u002Fwelcome\u002F",{"_key":375,"_type":76,"children":376,"level":137,"listItem":225,"markDefs":385,"style":84},"7d3d3d730225",[377,381],{"_key":378,"_type":80,"marks":379,"text":380},"7d3d3d7302250",[219],"Specific guidance for docs change requests:",{"_key":382,"_type":80,"marks":383,"text":384},"7d3d3d7302251",[]," Provide clear guidance for the contribution process. For example, specify branches on which to open change requests, any tags needed for documentation PRs, and any additional review processes required for documentation.",[],{"_key":387,"_type":76,"children":388,"level":137,"listItem":225,"markDefs":397,"style":84},"528b183f80e3",[389,393],{"_key":390,"_type":80,"marks":391,"text":392},"528b183f80e30",[219],"Answer contributors’ most common questions:",{"_key":394,"_type":80,"marks":395,"text":396},"528b183f80e31",[]," When you find yourself repeatedly answering the same contribution question, add that question (and its answer) to the contribution guide.",[],{"_key":399,"_type":76,"children":400,"markDefs":421,"style":84},"e7374debc0c6",[401,405,410,413,418],{"_key":402,"_type":80,"marks":403,"text":404},"e7374debc0c60",[],"For Kubernetes, we created a ",{"_key":406,"_type":80,"marks":407,"text":409},"e7374debc0c61",[408],"beb8a36c8810","general documentation contribution guide",{"_key":411,"_type":80,"marks":412,"text":359},"e7374debc0c62",[],{"_key":414,"_type":80,"marks":415,"text":417},"e7374debc0c63",[416],"55993afbfdba","guidance for filing a docs PR",{"_key":419,"_type":80,"marks":420,"text":108},"e7374debc0c64",[],[422,424],{"_key":408,"_type":111,"href":423,"reference":12},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fcontribute\u002Fnew-content\u002F",{"_key":416,"_type":111,"href":425,"reference":12},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fcontribute\u002Fnew-content\u002Fopen-a-pr\u002F",{"_key":427,"_type":76,"children":428,"markDefs":433,"style":121},"970393359e82",[429],{"_key":430,"_type":80,"marks":431,"text":432},"970393359e820",[],"Make it easy (and fun) for your contributors",[],{"_key":435,"_type":76,"children":436,"markDefs":441,"style":84},"6cb50ef769c9",[437],{"_key":438,"_type":80,"marks":439,"text":440},"6cb50ef769c90",[],"By providing a clear set of triaged issues and guidelines for contributors to follow, you can scale up your number of contributors. Remember that like code, the processes you’ve created for docs need regular review and maintenance. Review your issues regularly to triage them and remove any that become stale or outdated.",[],{"_key":443,"_type":76,"children":444,"markDefs":449,"style":84},"f85b21702990",[445],{"_key":446,"_type":80,"marks":447,"text":448},"f85b217029900",[],"Likewise, set a regular cadence for reviewing documentation PRs. Editdocumentation PRs both for editorial and technical quality and give your contributors timely and friendly feedback.",[],{"_key":451,"_type":76,"children":452,"markDefs":457,"style":84},"c34e90881092",[453],{"_key":454,"_type":80,"marks":455,"text":456},"c34e908810920",[],"Finally, recognize the contributors to your documentation. You don’t have to do anything as grand as the open-source peer bonus program. Thanking contributors in their PRs, announcing their names when doing a release, and publicly thanking them for their work on a project’s blog can go a long way to showing your gratitude.",[],{"_key":459,"_type":76,"children":460,"markDefs":473,"style":84},"1ffc22d4d267",[461,465,470],{"_key":462,"_type":80,"marks":463,"text":464},"1ffc22d4d2670",[182],"Jared Bhatti and Zachary Sarah Corleissen are Emeritus SIG-Docs Committee members of Kubernetes, and recently co-authored the book ",{"_key":466,"_type":80,"marks":467,"text":469},"1ffc22d4d2671",[468,182],"f13fba3d0a1a","Docs for Developers: An Engineer’s Field Guide to Technical Writing",{"_key":471,"_type":80,"marks":472,"text":108},"1ffc22d4d2672",[182],[474],{"_key":468,"_type":111,"href":475,"reference":12},"https:\u002F\u002Flink.springer.com\u002Fbook\u002F10.1007\u002F978-1-4842-7217-6",true,"2022\u002F05\u002F02","When your open-source project starts getting contributors, it can feel great! But as a project grows, contributors can neglect to document everything. ",{"_type":56,"asset":480},{"_ref":481,"_type":59},"image-04a0d02e6b9c42d8ef42c99ef9dd12cdaa728cb0-1200x675-jpg",{"code":483,"language":484},"\u003C!-- wp:paragraph -->\n\u003Cp>It’s exciting for open projects to grow from a handful of users to a team of collaborators working on and using the software. Moving from one to many contributors is a powerful moment for any project. However, as a project scales and grows, one area is frequently neglected: the documentation.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Missing or insufficient documentation hinders a project’s ability to scale. Most potential users skim your documentation first to see if it fits their needs and to judge how difficult it might be to use. Documentation makes your project’s first impression: not only on potential users, but also on potential contributors.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Writing and improving documentation offers a clear path for people to contribute to your project—provided you offer the right guidance and processes to support them. This article covers best practices for attracting and retaining open-source documentation contributors based on our experience building and managing documentation for \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fhome\u002F\">Kubernetes\u003C\u002Fa>.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-evaluate-your-existing-docs\">Evaluate your existing docs\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Begin by evaluating your existing documentation. You can’t ask for help from your contributors if you don’t know what you need! As you evaluate your documentation, consider it from the perspective of your users:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>What are my users’ needs? Do these docs meet their needs? \u003C\u002Fli>\u003Cli>Are there any features that are undocumented? Is critical information missing? Are there other content gaps to fill?\u003C\u002Fli>\u003Cli>What content is outdated and needs to be deleted? \u003C\u002Fli>\u003Cli>What content needs to be refactored and clarified?\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Don’t get bogged down trying to fix each issue you come across. Instead, open an issue for each problem you encounter.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Once you’ve evaluated your content, review the issues you opened and determine whether you need to fix any issues \u003Cem>before\u003C\u002Fem> you invite contributors to address them. For example, if your documentation consists of a single-page `README.md` file with 2,500 lines, breaking it up into smaller individual documents will lower the barrier for contributors. If your documentation contains outdated content, delete it so that new contributors can join more easily. Fix any issues you think would block new contributors from working on your content. \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-triage-your-doc-issues\">Triage your doc issues\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A simple doc issue triage process might look something like this: \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Now that you have a set of issues related to your documentation, apply triage. Triaging documentation issues is similar to triaging code issues: make sure an issue is valid and actionable and assign a priority.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003Cli>\u003Cstrong>Validate if the issue is related to your documentation and not related to your code: \u003C\u002Fstrong>It’s common for an issue to be related to both. Consider whether new documentation or a code change would help your users more. For example, if a CLI command has a confusing name, you could either document the command better or rename the command to something clearer.\u003C\u002Fli>\u003Cli>\u003Cstrong>Assess whether the issue is actionable:\u003C\u002Fstrong> Does the issue contain everything a contributor needs in order to fix the problem? Tag unclear issues with something like `needs more information` and follow up with the person who filed the issue. For example, an issue that reads only, “This didn’t work,” without specifying what didn’t work or how to fix it isn’t actionable. \u003C\u002Fli>\u003Cli>\u003Cstrong>Assign a priority to the issue:\u003C\u002Fstrong> What does the project need to fix first? You can use a priority numbering system (like P0-P4) or specify your priorities with tags like `now`,`next`, and `backlog`.\u003C\u002Fli>\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Finally, for new contributors, tag issues that are quick fixes or good first issues. A label like `good first issue` makes it easy for new contributors to identify issues they can take on when they’re getting started with your project. \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Kubernetes uses a \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fcontribute\u002Freview\u002Ffor-approvers\u002F#triage-and-categorize-issues\">doc issue triage process\u003C\u002Fa> very similar to the one listed above. \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-add-documentation-processes-to-your-contributor-guidelines\">Add documentation processes to your contributor guidelines\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Hopefully, you already have contributor guidelines (if not, GitHub has \u003Ca href=\"https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcommunities\u002Fsetting-up-your-project-for-healthy-contributions\u002Fsetting-guidelines-for-repository-contributors\">great guidance you can follow\u003C\u002Fa> in setting them out). In your guidelines, include guidance specific to documentation, including:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003Cli>\u003Cstrong>How documentation is written and served:\u003C\u002Fstrong> Indicate which markup language(s) you’re using, any documentation templates you’re using, and whether you’re using any tools like static site generators to display your content.\u003C\u002Fli>\u003Cli>\u003Cstrong>How documentation is organized:\u003C\u002Fstrong> Give clear guidance on what types of content belong where, including how files and folders are organized. Specify which kinds of content belong in product documentation and what content might be better suited to \u003Ca href=\"https:\u002F\u002Fstackoverflow.com\u002F\">Stack Overflow\u003C\u002Fa> or your project’s blog. \u003C\u002Fli>\u003Cli>\u003Cstrong>Any documentation standards:\u003C\u002Fstrong> Specify any naming conventions you’re using in your documentation. You can preempt a high volume of questions from your contributors about grammar, capitalization, and punctuation by following a public style guide. Both \u003Ca href=\"https:\u002F\u002Fdevelopers.google.com\u002Fstyle\">Google\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fdocs.microsoft.com\u002Fen-us\u002Fstyle-guide\u002Fwelcome\u002F\">Microsoft\u003C\u002Fa> provide public documentation style guides.\u003C\u002Fli>\u003Cli>\u003Cstrong>Specific guidance for docs change requests:\u003C\u002Fstrong> Provide clear guidance for the contribution process. For example, specify branches on which to open change requests, any tags needed for documentation PRs, and any additional review processes required for documentation.\u003C\u002Fli>\u003Cli>\u003Cstrong>Answer contributors’ most common questions:\u003C\u002Fstrong> When you find yourself repeatedly answering the same contribution question, add that question (and its answer) to the contribution guide.\u003C\u002Fli>\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>For Kubernetes, we created a \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fcontribute\u002Fnew-content\u002F\">general documentation contribution guide\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fcontribute\u002Fnew-content\u002Fopen-a-pr\u002F\">guidance for filing a docs PR\u003C\u002Fa>. \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-make-it-easy-and-fun-for-your-contributors\">Make it easy (and fun) for your contributors\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>By providing a clear set of triaged issues and guidelines for contributors to follow, you can scale up your number of contributors. Remember that like code, the processes you’ve created for docs need regular review and maintenance. Review your issues regularly to triage them and remove any that become stale or outdated.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Likewise, set a regular cadence for reviewing documentation PRs. Editdocumentation PRs both for editorial and technical quality and give your contributors timely and friendly feedback. \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Finally, recognize the contributors to your documentation. You don’t have to do anything as grand as the open-source peer bonus program. Thanking contributors in their PRs, announcing their names when doing a release, and publicly thanking them for their work on a project’s blog can go a long way to showing your gratitude. \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:separator -->\n\u003Chr class=\"wp-block-separator\"\u002F>\n\u003C!-- \u002Fwp:separator -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cem>Jared Bhatti and Zachary Sarah Corleissen are Emeritus SIG-Docs Committee members of Kubernetes, and recently co-authored the book \u003C\u002Fem>\u003Ca href=\"https:\u002F\u002Flink.springer.com\u002Fbook\u002F10.1007\u002F978-1-4842-7217-6\">\u003Cem>Docs for Developers: An Engineer’s Field Guide to Technical Writing\u003C\u002Fem>\u003C\u002Fa>\u003Cem>. \u003C\u002Fem>\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->","html","2022-05-02T14:56:00.000Z",{"current":487},"building-a-community-of-open-source-documentation-contributors",[489,497,502,506],{"_createdAt":490,"_id":491,"_rev":492,"_type":493,"_updatedAt":490,"slug":494,"title":496},"2023-05-23T16:43:21Z","wp-tagcat-code-for-a-living","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":495},"code-for-a-living","Code for a Living",{"_createdAt":490,"_id":498,"_rev":492,"_type":493,"_updatedAt":490,"slug":499,"title":501},"wp-tagcat-community",{"current":500},"community","Community",{"_createdAt":490,"_id":503,"_rev":492,"_type":493,"_updatedAt":490,"slug":504,"title":505},"wp-tagcat-documentation",{"current":505},"documentation",{"_createdAt":490,"_id":507,"_rev":508,"_type":493,"_updatedAt":509,"slug":510,"title":512},"wp-tagcat-open-source","usBIUY8SfRoXafnkrDdaLh","2025-02-28T11:18:45Z",{"current":511},"open-source","Open Source","Building a community of open-source documentation contributors",[515,521,527,533],{"_id":516,"publishedAt":517,"slug":518,"sponsored":12,"title":520},"28e560af-f0aa-4d46-bd90-f435ad604aa7","2026-06-26T14:00:27.102Z",{"_type":10,"current":519},"paging-charity-how-can-engineering-leaders-avoid-becoming-bond-villains","Paging Charity! How can engineering leaders avoid becoming Bond villains?",{"_id":522,"publishedAt":523,"slug":524,"sponsored":12,"title":526},"4b22c2a3-3779-4966-93eb-5230391dbdce","2026-06-23T14:08:58.595Z",{"_type":10,"current":525},"your-ai-shipped-a-backend-that-boots-that-is-the-whole-problem","Your AI shipped a backend that boots. That is the whole problem.",{"_id":528,"publishedAt":529,"slug":530,"sponsored":12,"title":532},"5cf362e1-fe7b-45af-b69c-914731c6a052","2026-06-23T14:00:00.000Z",{"_type":10,"current":531},"the-2026-developer-survey-is-now-open-for-human-developers-only","The 2026 Developer Survey is now open (for human developers only)!",{"_id":534,"publishedAt":535,"slug":536,"sponsored":12,"title":538},"30b995f7-7cb9-4dd8-bf71-d0685940a32b","2026-06-19T14:00:00.000Z",{"_type":10,"current":537},"dispatches-from-o-reilly-from-capabilities-to-responsibilities","Dispatches from O'Reilly: From capabilities to responsibilities",{"data":540,"sourceMap":-1},{"count":541,"lastTimestamp":542},3,"2023-05-25T09:47:51Z"]