|
| 1 | +# README.md template |
| 2 | + |
| 3 | +Use the guidelines in each section of this template to ensure consistency and readability of your README. The README resides in your package's GitHub repository at the root of its directory within the repo. It's also used as the package distribution page (NuGet, PyPi, npm, etc.) and as a Quickstart on docs.microsoft.com. See [README-EXAMPLE.md](README-EXAMPLE.md) for an example following this template. |
| 4 | + |
| 5 | +**Title**: The H1 of your README should be in the format: `# [Product Name] client library for [Language]` |
| 6 | + |
| 7 | +* All headings, including the H1, should use **sentence-style capitalization**. Refer to the [Microsoft Style Guide][style-guide-msft] and [Microsoft Cloud Style Guide][style-guide-cloud] for more information. |
| 8 | +* Example: `# Azure Batch client library for Python` |
| 9 | + |
| 10 | +# Azure Template client library for .NET |
| 11 | + |
| 12 | +**Introduction**: The introduction appears directly under the title (H1) of your README. |
| 13 | + |
| 14 | +* **DO NOT** use an "Introduction" or "Overview" heading (H2) for this section. |
| 15 | +* First sentence: **Describe the service** briefly. You can usually use the first line of the service's docs landing page for this (Example: [Cosmos DB docs landing page](https://docs.microsoft.com/azure/cosmos-db/)). |
| 16 | +* Next, add a **bulleted list** of the **most common tasks** supported by the package or library, prefaced with "Use the client library for [Product Name] to:". Then, provide code snippets for these tasks in the [Examples](#examples) section later in the document. Keep the task list short but include those tasks most developers need to perform with your package. |
| 17 | +* Include this single line of links targeting your product's content at the bottom of the introduction, making any adjustments as necessary (for example, NuGet instead of PyPi): |
| 18 | + |
| 19 | + [Source code](https://github.com/Azure/azure-sdk-for-python/tree/master/azure-batch) | [Package (PyPi)](https://pypi.org/project/azure-batch/) | [API reference documentation](https://docs.microsoft.com/python/api/overview/azure/batch?view=azure-python) | [Product documentation](https://docs.microsoft.com/azure/batch/) |
| 20 | + |
| 21 | +> TIP: Your README should be as **brief** as possible but **no more brief** than necessary to get a developer new to Azure, the service, or the package up and running quickly. Keep it brief, but include everything a developer needs to make their first API call successfully. |
| 22 | +
|
| 23 | +## Getting started |
| 24 | + |
| 25 | +This section should include everything a developer needs to do to install and create their first client connection *very quickly*. |
| 26 | + |
| 27 | +### Install the package |
| 28 | + |
| 29 | +First, provide instruction for obtaining and installing the package or library. This section might include only a single line of code, like `pip install package-name`, but should enable a developer to successfully install the package from NuGet, pip, npm, Maven, or even cloning a GitHub repository. |
| 30 | + |
| 31 | +Include a **Prerequisites** line after the install command that details any requirements that must be satisfied before a developer can [authenticate](#authenticate-the-client) and test all of the snippets in the [Examples](#examples) section. For example, for Cosmos DB: |
| 32 | + |
| 33 | +**Prerequisites**: You must have an [Azure subscription](https://azure.microsoft.com/free/), [Cosmos DB account](https://docs.microsoft.com/azure/cosmos-db/account-overview) (SQL API), and [Python 3.6+](https://www.python.org/downloads/) to use this package. |
| 34 | + |
| 35 | +### Authenticate the client |
| 36 | + |
| 37 | +If your library requires authentication for use, such as for Azure services, include instructions and example code needed for initializing and authenticating. |
| 38 | + |
| 39 | +For example, include details on obtaining an account key and endpoint URI, setting environment variables for each, and initializing the client object. |
| 40 | + |
| 41 | +## Key concepts |
| 42 | + |
| 43 | +The *Key concepts* section should describe the functionality of the main classes. Point out the most important and useful classes in the package (with links to their reference pages) and explain how those classes work together. Feel free to use bulleted lists, tables, code blocks, or even diagrams for clarity. |
| 44 | + |
| 45 | +## Examples |
| 46 | + |
| 47 | +Include code snippets and short descriptions for each task you listed in the [Introduction](#introduction) (the bulleted list). Briefly explain each operation, but include enough clarity to explain complex or otherwise tricky operations. |
| 48 | + |
| 49 | +If possible, use the same example snippets that your in-code documentation uses. For example, use the snippets in your `examples.py` that Sphinx ingests via its [literalinclude](https://www.sphinx-doc.org/en/1.5/markup/code.html?highlight=code%20examples#includes) directive. The `examples.py` file containing the snippets should reside alongside your package's code, and should be tested in an automated fashion. |
| 50 | + |
| 51 | +Each example in the *Examples* section starts with an H3 that describes the example. At the top of this section, just under the *Examples* H2, add a bulleted list linking to each example H3. Each example should deep-link to the types and/or members used in the example. |
| 52 | + |
| 53 | +* [Create the thing](#create-the-thing) |
| 54 | +* [Get the thing](#get-the-thing) |
| 55 | +* [List the things](#list-the-things) |
| 56 | + |
| 57 | +### Create the thing |
| 58 | + |
| 59 | +Use the [create_thing](not-valid-link) method to create a Thing reference; this method does not make a network call. To persist the Thing in the service, call [Thing.save](not-valid-link). |
| 60 | + |
| 61 | +```Python |
| 62 | +thing = client.create_thing(id, name) |
| 63 | +thing.save() |
| 64 | +``` |
| 65 | + |
| 66 | +### Get the thing |
| 67 | + |
| 68 | +The [get_thing](not-valid-link) method retrieves a Thing from the service. The `id` parameter is the unique ID of the Thing, not its "name" property. |
| 69 | + |
| 70 | +```C# Snippet:GetSecret |
| 71 | +var client = new MiniSecretClient(new Uri(endpoint), new DefaultAzureCredential()); |
| 72 | + |
| 73 | +SecretBundle secret = client.GetSecret("TestSecret"); |
| 74 | + |
| 75 | +Console.WriteLine(secret.Value); |
| 76 | +```Python |
| 77 | +things = client.list_things() |
| 78 | +``` |
| 79 | + |
| 80 | +## Troubleshooting |
| 81 | + |
| 82 | +Describe common errors and exceptions, how to "unpack" them if necessary, and include guidance for graceful handling and recovery. |
| 83 | + |
| 84 | +Provide information to help developers avoid throttling or other service-enforced errors they might encounter. For example, provide guidance and examples for using retry or connection policies in the API. |
| 85 | + |
| 86 | +If the package or a related package supports it, include tips for logging or enabling instrumentation to help them debug their code. |
| 87 | + |
| 88 | +## Next steps |
| 89 | + |
| 90 | +* Provide a link to additional code examples, ideally to those sitting alongside the README in the package's `/samples` directory. |
| 91 | +* If appropriate, point users to other packages that might be useful. |
| 92 | +* If you think there's a good chance that developers might stumble across your package in error (because they're searching for specific functionality and mistakenly think the package provides that functionality), point them to the packages they might be looking for. |
| 93 | + |
| 94 | +## Contributing |
| 95 | + |
| 96 | +This is a template, but your SDK readme should include details on how to contribute code to the repo/package. |
| 97 | + |
| 98 | +<!-- LINKS --> |
| 99 | +[style-guide-msft]: https://docs.microsoft.com/style-guide/capitalization |
| 100 | +[style-guide-cloud]: https://worldready.cloudapp.net/Styleguide/Read?id=2696&topicid=25357 |
| 101 | + |
| 102 | + |
0 commit comments