-
Notifications
You must be signed in to change notification settings - Fork 243
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Updating mark down files for launch of the official sdk betas
- Loading branch information
1 parent
83946af
commit 809751e
Showing
4 changed files
with
125 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,93 @@ | ||
| # Contributing | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| - [TODO] Recommended tools to use. (Editor, extensions, etc.) | ||
| - [TODO] Minimum required version of rustup / rustc / cargo | ||
|
|
||
| ## Generated code | ||
|
|
||
| If you want to contribute to a file that is generated (header contains `Code generated by Microsoft (R) AutoRest Code Generator.`), the best approach to open a PR on the initial Swagger/TypeSpec specification, as we can NOT merge a PR on generated code (it would be replaced by next generation). Please visit the [Azure/azure-rest-api-specs repo](https://github.com/Azure/azure-rest-api-specs/) to view and make changes to Azure service API specs. | ||
|
|
||
| ## Building | ||
|
|
||
| [TODO] Add instructions on how to build a specific library or the entire repo if possible. | ||
|
|
||
| ## Testing | ||
|
|
||
| [TODO] Add instructions on how to run tests for a specific project. | ||
| [TODO] Add instructions for write new tests. | ||
|
|
||
| ## Code Review Process | ||
|
|
||
| Before a pull request will be considered by the Azure SDK team, the following requirements must be met: | ||
|
|
||
| - Prior to issuing the pull request: | ||
| - All code must have completed any necessary legal sign-off for being publicly viewable (Patent review, JSR review, etc.) | ||
| - The changes cannot break any existing functional/unit tests that are part of the central repository. | ||
| - This includes all tests, even those not associated with the given feature area | ||
| - Code submitted must have basic unit test coverage, and have all unit tests pass. Testing is the full responsibility of person submitting the code review. | ||
| - Functional tests are encouraged, and provide teams with a way to mitigate regressions cause by other code contributions. | ||
| - Code should be commented. | ||
| - Code should be fully code reviewed. | ||
| - Code should be able to merge without any conflicts into the dev branch being targeted. | ||
| - Code should pass all relevant static checks and coding guidelines set forth by the specific repository. | ||
| - All build warnings and code analysis warnings should be fixed prior to submission. | ||
| - As part of the pull request (aka, in the text box on GitHub as part of submitting the pull request): | ||
| - Proof of completion of the code review and test passes requirements above. | ||
| - Identity of QA responsible for feature testing (can be conducted post-merging of the pull request). | ||
| - Short description of the payload of pull request. | ||
| - After the pull request is submitted: | ||
| - When your PR is submitted someone on our team will be auto assigned the PR for review. No need to email us. | ||
|
|
||
| Once all of the above steps are met, the following process will be followed: | ||
|
|
||
| - A member of the Azure SDK team will review the pull request on GitHub. | ||
| - If the pull request meets the repository's requirements, the individual will approve the pull request, merging the code into the appropriate branch of the source repository. | ||
| - If the request does not meet any of the requirements, the pull request will not be merged, and the necessary fixes for acceptance will be communicated back to the person who opened the PR. | ||
|
|
||
| ### Pull Request Etiquette and Best Practices | ||
|
|
||
| #### Reviewers | ||
|
|
||
| - If you disagree with the overall approach of the PR, comment on the general PR rather than individual lines of code. | ||
| - Leaving [suggested changes](https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request) is welcomed, but please never commit them for a PR you did not create. | ||
| - When you are seeking to understand something rather than request corrections, it is suggested to use language such as "I'm curious ..." as a prefix to comments. | ||
| - For comments that are just optional suggestions or are explicitly non-blocking, prefix them with "nit: " or "non-blocking: ". | ||
| - Avoid marking a PR as "Request Changes"  unless you have serious concerns that should block the PR from merging. | ||
| - When to mark a PR as "Approved" | ||
| - You feel confident that the code meets a high quality bar, has adequate test coverage, is ready to merge. | ||
| - You have left comments that are uncontroversial and there is a shared understanding with the author that the comments can be addressed or resolved prior to being merged without significant discussion or significant change to the design or approach. | ||
| - When to leave comments without approval | ||
| - You do not feel confident that your review alone is sufficient to call the PR ready to merge. | ||
| - You have feedback that may require detailed discussion or may indicate a need to change the current design or approach in a non-trivial way. | ||
| - When to mark a PR as "Request Changes" | ||
| - You have significant concerns that must be addressed before this PR should be merged such as unintentional breaking changes, security issues, or potential data loss. | ||
|
|
||
| #### Pull Request Authors | ||
|
|
||
| - If you add significant changes to a PR after it has been marked approved, please confirm with reviewers that they still approve before merging. | ||
| - Please ensure that you have obtained an approval from at least one of the code owners before merging. | ||
| - If a reviewer marks your PR as approved along with specific comments, it is expected that those comments will be addressed or resolved prior to merging. | ||
| - One exception is when a comment clearly states that the feedback is optional or just a nit | ||
| - When in doubt, reach out to the commentor to confirm that they have no concerns with you merging without addressing a comment. | ||
|
|
||
| ## Samples | ||
|
|
||
| ### Third-party dependencies | ||
|
|
||
| Third party libraries should only be included in samples when necessary to demonstrate usage of an Azure SDK package; they should not be suggested or endorsed as alternatives to the Azure SDK. | ||
|
|
||
| When code samples take dependencies, readers should be able to use the material without significant license burden or research on terms. This goal requires restricting dependencies to certain types of open source or commercial licenses. | ||
|
|
||
| Samples may take the following categories of dependencies: | ||
|
|
||
| - **Open-source** : Open source offerings that use an [Open Source Initiative (OSI) approved license](https://opensource.org/licenses). Any component whose license isn't OSI-approved is considered a commercial offering. Prefer OSS projects that are members of any of the [OSS foundations that Microsoft is part of](https://opensource.microsoft.com/ecosystem/). Prefer permissive licenses for libraries, like [MIT](https://opensource.org/licenses/MIT) and [Apache 2](https://opensource.org/licenses/Apache-2.0). Copy-left licenses like [GPL](https://opensource.org/licenses/gpl-license) are acceptable for tools, and OSs. [Kubernetes](https://github.com/kubernetes/kubernetes), [Linux](https://github.com/torvalds/linux), and [Newtonsoft.Json](https://github.com/JamesNK/Newtonsoft.Json) are examples of this license type. Links to open source components should be to where the source is hosted, including any applicable license, such as a GitHub repository (or similar). | ||
|
|
||
| - **Commercial**: Commercial offerings that enable readers to learn from our content without unnecessary extra costs. Typically, the offering has some form of a community edition, or a free trial sufficient for its use in content. A commercial license may be a form of dual-license, or tiered license. Links to commercial components should be to the commercial site for the software, even if the source software is hosted publicly on GitHub (or similar). | ||
|
|
||
| - **Dual licensed**: Commercial offerings that enable readers to choose either license based on their needs. For example, if the offering has an OSS and commercial license, readers can choose between them. [MySql](https://github.com/mysql/mysql-server) is an example of this license type. | ||
|
|
||
| - **Tiered licensed**: Offerings that enable readers to use the license tier that corresponds to their characteristics. For example, tiers may be available for students, hobbyists, or companies with defined revenue thresholds. For offerings with tiered licenses, strive to limit our use in tutorials to the features available in the lowest tier. This policy enables the widest audience for the article. [Docker](https://www.docker.com/), [IdentityServer](https://duendesoftware.com/products/identityserver), [ImageSharp](https://sixlabors.com/products/imagesharp/), and [Visual Studio](https://visualstudio.com) are examples of this license type. | ||
|
|
||
| In general, we prefer taking dependencies on licensed components in the order of the listed categories. In cases where the category may not be well known, we'll document the category so that readers understand the choice that they're making by using that dependency. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,4 @@ | ||
| MIT License | ||
| The MIT License (MIT) | ||
|
|
||
| Copyright (c) Microsoft Corporation. | ||
|
|
||
|
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,14 +1,33 @@ | ||
| # Support | ||
|
|
||
| ## How to file issues and get help | ||
| ## How to file issues and get help | ||
|
|
||
| This project uses GitHub Issues to track bugs and feature requests. Please search the existing | ||
| issues before filing new issues to avoid duplicates. For new issues, file your bug or | ||
| feature request as a new Issue. | ||
| ### Azure support tickets | ||
|
|
||
| For help and questions about using this product, please join the discussion on existing | ||
| [issues](https://github.com/azure/azure-sdk-for-rust/issues) or create a new issue. | ||
| Customers with an [Azure support plan](https://azure.microsoft.com/support/options/) can open an [Azure support ticket](https://azure.microsoft.com/support/create-ticket/). | ||
| **We recommend this option if your problem requires immediate attention.** | ||
|
|
||
| ### GitHub issues | ||
|
|
||
| We use [GitHub Issues](https://github.com/Azure/azure-sdk-for-net/issues/new/choose) to track bugs, questions, and feature requests. | ||
| GitHub issues are free, but **response time is not guaranteed.** See [GitHub issues support process](https://devblogs.microsoft.com/azure-sdk/github-issue-support-process/) for more details. | ||
|
|
||
| To ensure the relevance and manageability of our issue queue, we have an automated process that will close issues that are over two years old and have not been updated in the last 30 days. This measure is designed to help us respond to and resolve current issues more efficiently. We appreciate your understanding and cooperation in maintaining a focused and up-to-date issue tracking system. | ||
|
|
||
| ### Community resources | ||
| - Take a look at the [Azure SDK blog](https://devblogs.microsoft.com/azure-sdk/). | ||
| - Search for similar issues in [our GitHub repository](https://github.com/Azure/azure-sdk-for-rust/issues) | ||
| - Ask a question on [StackOverflow](https://stackoverflow.com/questions/tagged/azure-sdk-rust) and tag it with azure-sdk-.net | ||
| - Share or upvote feature requests on [Feedback Page](https://feedback.azure.com/forums/34192--general-feedback). | ||
| - Ask a question on [Twitter](https://twitter.com/AzureSDK) | ||
| - Ask a question at [Microsoft Q&A](https://docs.microsoft.com/answers/products/azure?WT.mc_id=Portal-Microsoft_Azure_Support&product=all) | ||
| - Ask a question at [Microsoft Tech Community](https://techcommunity.microsoft.com/t5/azure/ct-p/Azure) | ||
|
|
||
| ### Security bugs | ||
| Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center([email protected]). | ||
| You should receive a response within 24 hours. | ||
| Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://www.microsoft.com/msrc/faqs-report-an-issue?rtc=1) | ||
|
|
||
| ## Microsoft Support Policy | ||
|
|
||
| Support for this project is limited to the resources listed above. | ||
| Please refer to [Azure SDK Support and Lifecycle information](https://azure.github.io/azure-sdk/policies_support.html) |