From c7f712f7f8d041ad141e41e456633955829bcb67 Mon Sep 17 00:00:00 2001
From: hborawski <Harris_Borawski@intuit.com>
Date: Fri, 29 Sep 2023 13:50:49 -0700
Subject: [PATCH] update CONTRIBUTING doc with more system info, update
 templates

---
 .github/ISSUE_TEMPLATE/bug_report.md |  1 +
 .github/PULL_REQUEST_TEMPLATE.md     | 25 +++++++++++++++++++++----
 CONTRIBUTING.md                      | 26 +++++++++++++++++++++++++-
 3 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
index 2d0ceb65c..68ae6e794 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.md
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -13,6 +13,7 @@ assignees: ""
 **To Reproduce**
 
 <!-- Steps to reproduce the behavior: -->
+<!-- If possible JSON content utilizing reference assets to illustrate the issue -->
 
 **Expected behavior**
 
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 66e58b1fd..fb7ed35a5 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -8,10 +8,27 @@ Make sure to add:
 
 -->
 
+
+### Change Type (required)
+Indicate the type of change your pull request is:
+
 <!-- 
-    Does the change need more description than just he PR title? 
-    Uncomment the line below and write some release notes 
+  We use semantic versioning: https://semver.org/. Review that documentation for 
+  more detailed guidelines.
 -->
+- [ ] `patch`
+- [ ] `minor`
+- [ ] `major`
+
+<!--
+  To include release notes in the automatic changelong, just add a level 1 markdown header below
+  and include any markdown notes to go into the changelog: https://intuit.github.io/auto/docs/generated/changelog#additional-release-notes
+
+  Example:
 
-<!-- ## Release Notes -->
-<!-- <release notes here> -->
\ No newline at end of file
+  # Release Notes
+  Added new plugin, to use it:
+  ```typescript
+  const plugin = new Plugin(...)
+  ```
+-->
\ No newline at end of file
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b67268592..6802c6d1a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -11,10 +11,25 @@ If the changes are larger (API design, architecture, etc), [opening an issue](ht
 ## Requirements
 * [npm >= 8.19.2](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)
 * [yarn >= 1.22.19](https://yarnpkg.com/)
+
 * [Swift >= 5.2](https://www.swift.org/download/)
+* [Xcode 14.3](https://developer.apple.com/download/all/) 
+* [Ruby >= 2.6 && <= 3.0](https://github.com/rbenv/rbenv)
+
 * [Android NDK >= 19.2.5345600, <= 21](https://github.com/android/ndk/wiki/Unsupported-Downloads#r19c). Any version > 21 will not work, period. You'll need to add `ANDROID_NDK_HOME` to your environment manually.
 
 ## Building and Testing Locally
+#### Presetup
+For iOS builds, some pre-setup is required for `bazel` to generate BUILD files for dependent CocoaPods.
+
+```bash
+bundle install
+```
+CocoaPods does not directly integrate with `bazel`, when core targets are updated, the output bundles need to be copied to the location described in the `PlayerUI.podspec`, to do so run the script:
+```bash
+./tools/build_ios_bundles.sh
+```
+This will query `bazel` for dependent targets, copy their output and regenerate the `.xcworkspace`.
 ### Player
 For speed and consistency, this repo leverages `bazel` as it's main build tool. Check out the [bazel](https://bazel.build/) docs for more info.
 
@@ -30,6 +45,13 @@ Tests can also be ran using:
 bazel test //...
 ```
 
+#### Skipping iOS builds
+The `.bazelrc` contains a convenience to build everything but the iOS targets, as the toolchain for those is platform specific.
+
+```bash
+bazel build --config=skip-ios
+```
+
 ### Docs Sites
 These require the [Android NDK](https://developer.android.com/ndk).
 The docs site can be ran using:
@@ -43,7 +65,9 @@ which will run an instance on `http://localhost:3000`.
 
 ## Submitting a Pull Request
 
-Please ensure that any new features have sufficient tests, code coverage, and documentation. 
+Prior to submitting a pull request, ensure that your fork and branch are up to date with the lastest changes on `main`. 
+
+Any new features should have corresponding tests that exercise all code paths, and public symbols should have docstrings at a minimum. For more complex features, adding new documentation pages to the site to help guide users to consume the feature would be preferred.
 
 When you're ready, submit a new pull request to the `main` branch and the team will be notified of the new requested changes. We'll do our best to respond as soon as we can.