<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Suggested Dapr docs templates on Dapr Docs</title><link>https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/</link><description>Recent content in Suggested Dapr docs templates on Dapr Docs</description><generator>Hugo</generator><language>en</language><atom:link href="https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/index.xml" rel="self" type="application/rss+xml"/><item><title>Conceptual article template</title><link>https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/concept-template/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/concept-template/</guid><description>&lt;h2 id="contributing-a-new-conceptual-or-overview-article">Contributing a new conceptual or overview article&lt;/h2>
&lt;p>Conceptual (or overview) articles answer the questions:&lt;/p>
&lt;ul>
&lt;li>Why should you care about this feature?&lt;/li>
&lt;li>What problems does it help you solve?&lt;/li>
&lt;/ul>
&lt;p>While a component, API, or SDK spec may help readers understand how to use or work with these features, a conceptual article provides more depth and context. Link off to the spec article, but try not to simply repeat the spec.&lt;/p>
&lt;p>When naming your conceptual article, make sure it is consistent with the spec in terms of names, parameters, and terminology. Make sure you update both as needed.&lt;/p></description></item><item><title>Quickstart guide template</title><link>https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/quickstart-template/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/quickstart-template/</guid><description>&lt;h2 id="contributing-a-new-quickstart-guide">Contributing a new quickstart guide&lt;/h2>
&lt;p>Dapr quickstart guides consist of quick instructions that walk readers through a prepared quickstart, saved to the &lt;a href="https://github.com/dapr/quickstarts">dapr/quickstarts repo&lt;/a>. These quickstarts package an entire feature or building block in one place, making it easy for the reader to experience how it works without compromising their own project.&lt;/p>
&lt;p>The quickstart instructions should be succinct, direct, and clear. The sole purpose of a quickstart guide is to simply instruct a reader through the prepared quickstart. If you&amp;rsquo;d like to explain the concepts behind the quickstart, direct the reader to a concept article for more context.&lt;/p></description></item><item><title>How-to guide template</title><link>https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/howto-template/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://v1-18.docs.dapr.io/contributing/docs-contrib/docs-templates/howto-template/</guid><description>&lt;h2 id="contributing-a-new-how-to-guide">Contributing a new how-to guide&lt;/h2>
&lt;p>How-to guides provide step-by-step practical guidance to readers who wish to:&lt;/p>
&lt;ul>
&lt;li>Enable a feature&lt;/li>
&lt;li>Integrate a technology&lt;/li>
&lt;li>Use Dapr in a specific scenario&lt;/li>
&lt;/ul>
&lt;p>How-to guides can be considered &amp;ldquo;next-level&amp;rdquo;, self-guided docs compared to quickstarts. How-to scenarios will take longer and can be more easily applied to the reader&amp;rsquo;s individual project or environment.&lt;/p>
&lt;p>When naming your how-to document, include the sub-directory name in the file name. If you need to create a new sub-directory, make sure it&amp;rsquo;s descriptive and includes the relevant component or concept name. For example, &lt;em>pubsub-namespaces&lt;/em>.&lt;/p></description></item></channel></rss>