navalev · navalev · Jan 7, 2020 · Jan 7, 2020 · Jan 7, 2020 · Jan 7, 2020
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
@@ -6,33 +6,37 @@
 ###########
 
 # Catch all
-/sdk/ @joshfree @jonathangiles
+/sdk/                                               @joshfree @jonathangiles
+
+# BOM
+/sdk/boms/azure-sdk-bom/                            @alzimmermsft @jonathangiles
 
 # Service teams
-/sdk/appconfiguration/                            	@mssfang @alzimmermsft @conniey @sima-zhu
-/sdk/batch/                                      	@xingwu1 @bgklein @matthchr
-/sdk/core/                                        	@alzimmermsft @jianghaolu @srnagar @hemanttanwar
-/sdk/cosmos/                                      	@moderakh @christopheranderson @kushagraThapar
-/sdk/eventhubs/                                   	@conniey @srnagar @mssfang
-/sdk/identity/                                    	@jianghaolu @g2vinay @hemanttanwar
-/sdk/keyvault/                                    	@g2vinay @samvaity
-/sdk/servicebus/                                  	@yvgopal @nemakam
-/sdk/tracing/                                    	@samvaity @alzimmermsft
-
-/sdk/storage/                				@rickle-msft @jaschrep-msft @gapra-msft @alzimmermsft @sima-zhu
+/sdk/appconfiguration/                              @mssfang @alzimmermsft @conniey @sima-zhu
+/sdk/batch/                                         @xingwu1 @bgklein @matthchr
+/sdk/core/                                          @alzimmermsft @jianghaolu @srnagar @hemanttanwar
+/sdk/cosmos/                                        @moderakh @christopheranderson @kushagraThapar
+/sdk/eventhubs/                                     @conniey @srnagar @mssfang
+/sdk/identity/                                      @jianghaolu @g2vinay @hemanttanwar
+/sdk/keyvault/                                      @g2vinay @samvaity
+/sdk/servicebus/                                    @yvgopal @nemakam
+/sdk/textanalytics/                                 @samvaity @mssfang
+/sdk/tracing/                                       @samvaity @alzimmermsft
+
+/sdk/storage/                                       @rickle-msft @jaschrep-msft @gapra-msft @alzimmermsft @sima-zhu
 
 # Management Plane
-/**/resource-manager/                            	@yaohaizh
-/sdk/**/azure-mgmt-*/                            	@yaohaizh
+/**/resource-manager/                               @yaohaizh
+/sdk/**/azure-mgmt-*/                               @yaohaizh
 
 ###########
 # Eng Sys
 ###########
-/eng/                               @JimSuplizio @mitchdenny @weshaggard @danieljurek
-/eng/code-quality-reports/          @mssfang @JonathanGiles
-/eng/jacoco-test-coverage/          @srnagar @JonathanGiles
-/eng/spotbugs-aggregate-report/     @srnagar @JonathanGiles
-/parent/                            @JimSuplizio
-
-/**/tests.yml   @danieljurek
-/**/ci.yml      @mitchdenny
+/eng/                                               @JimSuplizio @mitchdenny @weshaggard @danieljurek
+/eng/code-quality-reports/                          @mssfang @JonathanGiles
+/eng/jacoco-test-coverage/                          @srnagar @JonathanGiles
+/eng/spotbugs-aggregate-report/                     @srnagar @JonathanGiles
+/parent/                                            @JimSuplizio
+
+/**/tests.yml                                       @danieljurek
+/**/ci.yml                                          @mitchdenny
diff --git a/.github/PULL_REQUEST_TEMPLATE/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,25 @@
+<!-- DO NOT DELETE THIS TEMPLATE -->
+#Azure SDK for Java Pull Request Template Guide
+
+Thank you for your interest in contributing to Azure SDK for Java.
+
+## Description
+<!--
+Please add an informative description that covers that changes made by the pull request.
+
+If you are regenerating your SDK based off of a new swagger spec, please add the link to the corresponding swagger spec pull request that has been merged in the azure-rest-api-specs repository
+-->
+
+---
+
+This checklist is used to make sure that common guidelines for a pull request are followed.
+- [ ] Please add REST spec PR link to the SDK PR
+- [ ] **I have read the [contribution guidelines](../../CONTRIBUTING.md).**
+- [ ] **The pull request does not introduce breaking changes.**
+
+### [General Guidelines](../../CONTRIBUTING.md#Pull Requests)
+- [ ] Title of the pull request is clear and informative.
+- [ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, [see this page](../../CONTRIBUTING.md#Pull Requests).
+
+### [Testing Guidelines](../../CONTRIBUTING.md#Building and Testing)
+- [ ] Pull request includes test coverage for the included changes.
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, 
+disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [Azure SDK](mailto:azjavasdkhelp@microsoft.com). All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -67,7 +67,8 @@ mvn -f pom.client.xml -Dgpg.skip -DskipTests clean install
 - `clean:` will remove any previous generated output.
 - `install:`  compiles project and installs it in the local Maven cache.
 
->**Note**: Refer to [wiki](https://github.com/Azure/azure-sdk-for-java/wiki/Building) for learning about how to build using Java 11
+>**Note**: Refer to [wiki](https://github.com/Azure/azure-sdk-for-java/wiki/Building) for learning about how to build using Java 11 
+>and [this wiki](https://github.com/Azure/azure-sdk-for-java/wiki/Unit-Testing) for guidelines on unit testing
 
 ### Compiling one project only
 
@@ -103,7 +104,7 @@ Unreleased Dependency version – Whenever possible, libraries should be using t
 
 An example of Current vs Dependency versions: `com.azure:azure-storage-blob-batch` has dependencies on `com.azure:azure-core`, `com.azure:azure-core-http-netty` and `com.azure:azure-storage-blob`. Because `com.azure:azure-core` and `com.azure:azure-core-http-netty` are both built outside of azure-storage pipeline we should be using the released or *Dependency* versions of these when they're dependencies of another library. Similarly, libraries built as part of the same pipeline, that have interdependencies, should be using the Current version. Since `com.azure:azure-storage-blob-batch` and `com.azure:azure-storage-blob` are both built part of the azure-batch pipeline when `com.azure:azure-storage-blob` is declared as a dependency of `com.azure:azure-storage-blob-batch` it should be the *Current* version.
 
-An example of an Unreleased Dependency version: Additive, not breaking, API changes have been made to `com.azure:azure-core`. `com.azure:azure-storage-blob` has a dependency on `com.azure:azure-core` and requires the additive API change that has not yet been released. An unreleased entry needs to be created in [version_client.txt](./eng/versioning/version_client.txt), under the unreleased section, with the following format: `unreleased_<groupId>:<artifactId>;dependency-version`, in this example that would be `unreleased_com.azure:azure-core;1.2.0-beta.1` (this should match the 'current' version of core). The dependency update tags in the pom files that required this dependency would now reference `{x-version-update;unreleased_com.azure:azure-core;dependency}`. Once the updated library has been released the unreleased dependency version should be removed and the POM file update tags should be referencing the released version.
+An example of an Unreleased Dependency version: Additive, not breaking, API changes have been made to `com.azure:azure-core`. `com.azure:azure-storage-blob` has a dependency on `com.azure:azure-core` and requires the additive API change that has not yet been released. An unreleased entry needs to be created in [version_client.txt](./eng/versioning/version_client.txt), under the unreleased section, with the following format: `unreleased_<groupId>:<artifactId>;dependency-version`, in this example that would be `unreleased_com.azure:azure-core;1.2.0` (this should match the 'current' version of core). The dependency update tags in the pom files that required this dependency would now reference `{x-version-update;unreleased_com.azure:azure-core;dependency}`. Once the updated library has been released the unreleased dependency version should be removed and the POM file update tags should be referencing the released version.
 
 ### Tooling, version files and marker tags
 
@@ -140,9 +141,7 @@ In README files this ends up being slightly different. Because the version tag i
 Let's say we've GA'd and I need to tick up the version of azure-storage libraries how would I do it? Guidelines for incrementing versions after release can be found [here](https://github.com/Azure/azure-sdk/blob/master/docs/policies/releases.md#incrementing-after-release).
 
 1. I'd open up eng\versioning\version_client.txt and update the current-versions of the libraries that are built and released as part of the azure storage pipeline. This list can be found in pom.service.xml under the sdk/storage directory. It's worth noting that any module entry starting with "../" are external module dependencies and not something that's released as part of the pipeline. Dependencies for library components outside of a given area would be downloading the appropriate dependency from Maven like we do for external dependencies.
-2. Execute the update_versions python script from the root of the enlistment
-`python eng/versioning/update_versions.py --ut libary --bt client`
-This will go through the entire source tree and update all of the references in the POM and README files with the updated versions. Git status will show all of the modified files.
+2. Execute the update_versions python script from the root of the enlistment. The exact syntax and commands will vary based upon what is being changed and some examples can be found in the use cases in the [update_versions.py](./eng/versioning/update_versions.py#L6) file.
 3. Review and submit a PR with the modified files.
 
 ### Next steps: Management plane