Add support doc, update links

Signed-off-by: Vui Lam <[email protected]>

CONTRIBUTING.md

@@ -20,6 +20,12 @@ We welcome many different types of contributions and not all of them need a Pull
 * Helping to onboard new contributors
 * Other related activities
 
+## Roadmap
+
+The near-term and mid-term roadmap for the work planned for this project and
+the Tanzu CLI project is documented in the
+[Tanzu CLI Project Roadmap](https://github.com/vmware-tanzu/tanzu-cli/blob/main/ROADMAP.md).
+
 ## Getting started
 
 Details about how to get started with the project can be found in the development [guide](docs/dev.md).

README.md

@@ -18,7 +18,7 @@ methods to develop Tanzu CLI plugins.
 Developers begin plugin development by using the `builder` plugin to bootstrap
 a new plugin project. The code generated in the project relies on the runtime
 to provide some functionality common to all plugins. For more information about
-the development process, see the <!-- (VVV update link) --> [Tanzu CLI Plugin Development guide](https://github.com/vuil/tanzu-cli/blob/docs-draft/docs/plugindev/main.md)
+the development process, see the [Tanzu CLI Plugin Development guide](https://github.com/vmware-tanzu/tanzu-cli/blob/main/docs/plugindev/README.md)
 
 ## The library
 
@@ -54,7 +54,7 @@ For more details about the design and APIs go to [Configuration Library](docs/co
 This package implements helper functions for new plugin creation. This is one
 of the main packages that each and every plugin will need to import to
 integrate with the Tanzu CLI. For more information about
-the development process, see the <!-- (VVV update link) --> [Tanzu CLI Plugin Development guide](https://github.com/vuil/tanzu-cli/blob/docs-draft/docs/dev/main.md)
+the development process, see the [Tanzu CLI Plugin Development guide](https://github.com/vmware-tanzu/tanzu-cli/blob/main/docs/plugindev/README.md)
 
 ### Command Helpers
 
@@ -80,3 +80,14 @@ provided by different versions of plugin runtimes to ensure that they can
 interoperate with one another.
 
 For more details go to [Cross-version API Compatibility](test/compatibility/docs/cross-version-api-compatibility.md)
+
+## Contributing
+
+Thanks for taking the time to join our community and start contributing! We
+welcome pull requests. Feel free to dig through the
+[issues](https://github.com/vmware-tanzu/tanzu-plugin-runtime/issues) and jump in.
+
+### Before you begin
+
+- Check out the [contribution guidelines](CONTRIBUTING.md) to learn more about how to contribute.
+- Check out the document [here](docs/community/support.md) about the project's support process.

docs/community/support.md

@@ -0,0 +1,82 @@
+# Tanzu Plugin Runtime Support Process
+
+## Definitions
+
+* **Tanzu CLI member** - is a person who is an active contributor and with
+  write access to the `tanzu-plugin-runtime` repo.
+* **Critical urgent issue** - is an issue that severely impacts the use of the
+  software and has no workarounds. This kind of issue should be labeled with
+  [`severity-1`](https://github.com/vmware-tanzu/tanzu-plugin-runtime/labels/severity-1).
+
+## Weekly rotations
+
+The Tanzu CLI members use a weekly rotation to manage community support.
+Each week, a different member is the point person for triaging the new issues
+and guiding severity-1 issues to the best state to be tackled.
+
+The point person is not expected to solve every critical(severity-1) issue or
+be on-call 24x7. Instead, they will communicate expectations for the critical
+urgent issues to the community and ensure the issues are in the best position
+to be addressed.
+
+The point person is not expected to be involved with normal non-critical
+priority(other than severity-1) issues.
+
+## Start of Week
+
+Support schedule will be provided to ensure everyone knows when their support
+week is occurring.
+
+The schedule will consist of members who provide a week of their expertise to
+ensure new issues receive the labeling they need.
+
+They also work closely with the community to ensure the issue is properly
+detailed and have steps for reproducing the issue, if appropriate.
+
+Point people are responsible for ensuring they are active and managing the
+issue backlog during their scheduled week.
+
+## During the Week
+
+The point person will monitor:
+
+* New issues labeled with * [`needs-triage`](https://github.com/vmware-tanzu/tanzu-plugin-runtime/labels/needs-triage).
+* Currently, open issues labeled as [`investigating` and * `triage/needs-info`](https://github.com/vmware-tanzu/tanzu-plugin-runtime/issues?q=label%3Atriage%2Fneeds-info%2Cinvestigating+is%3Aopen)
+.
+* Open issues labeled as * [`severity-1`](https://github.com/vmware-tanzu/tanzu-plugin-runtime/labels/severity-1).
+
+These issues can also be viewed [with a single aggregating query](https://github.com/vmware-tanzu/tanzu-plugin-runtime/issues?q=label%3Atriage%2Fneeds-info%2Cinvestigating%2Cseverity-1%2Cneeds-triage+is%3Aopen).
+
+### GitHub issue flow
+
+Generally speaking, new GitHub issues will fall into one of several categories.
+The point person will use the following process for each issue:
+
+* Feature request
+  * Label the issue with `kind/feature`.
+  * Determine the area of the runtime the issue belongs to and add appropriate
+    [area](https://github.com/vmware-tanzu/tanzu-plugin-runtime/labels?q=area) label.
+  * Remove `needs-triage` label.
+* Bug
+  * Label the issue with `kind/bug`.
+  * Determine the area of the runtime the issue belongs to and add appropriate
+    [area](https://github.com/vmware-tanzu/tanzu-plugin-runtime/labels?q=area) label.
+  * If the issue is critical urgent, it should be labeled as `severity-1`.
+  * Remove `needs-triage` label.
+* User question/problem that does not fall into one of the previous categories
+  * Assign the issue to yourself.
+  * When you start investigating/responding, label the issue with `investigating`.
+  * Add context for both the user and future support people.
+  * Use the `triage/needs-info` label to indicate an issue is waiting for
+  information from the user. If you do not get a response in 20 days then close
+  the issue with an appropriate comment.
+  * If you resolve the issue, add the resolution as a comment on the issue and
+  close it.
+  * If the issue ends up being a feature request or a bug, update the labels
+  and follow the appropriate process for it.
+
+## End of Week
+
+The point person will ensure all GitHub issues worked on during the week are
+labeled with `investigating` and `triage/needs-info` (if appropriate), and have
+updated comments, so the next person can pick them up.

docs/config.md

@@ -2,11 +2,20 @@
 
 ## Overview
 
-Config library provides various API methods to store plugin discovery sources, contexts, features and configuration options in Tanzu CLI configuration (stored in $HOME/.config/tanzu/config.yaml and $HOME/.config/tanzu/config-ng.yaml).
+Config library provides various API methods to store plugin discovery sources,
+contexts, features and configuration options in Tanzu CLI configuration (stored
+in $HOME/.config/tanzu/config.yaml and $HOME/.config/tanzu/config-ng.yaml).
 
-To learn more about plugin repository, contexts, features and configuration options, please refer [Tanzu CLI User Guide](https://github.com/vmware-tanzu/tanzu-cli/blob/docs-draft/docs/full/README.md#tanzu-cli-user-guide)
+To learn more about plugin repository, contexts, features and configuration options, please refer to the
+[Tanzu CLI User Guide](https://github.com/vmware-tanzu/tanzu-cli/blob/main/docs/full/README.md).
 
-Before tanzu-plugin-runtime version 0.28, CLI has only one configuration file which is CFG. In tanzu-plugin-runtime version 0.28, a new configuration file CFG_NG has been added to accommodate new configuration objects (Ex: context object which was referred as server in older tanzu-plugin-runtime version), and inter-operate with old and new tanzu-plugin-runtime client APIs (through plugin). CLI Runtime library unifies both configuration files for end user interactions.
+Before tanzu-plugin-runtime version 0.28, CLI has only one configuration file
+which is CFG. In tanzu-plugin-runtime version 0.28, a new configuration file
+CFG_NG has been added to accommodate new configuration objects (Ex: context
+object which was referred as server in older tanzu-plugin-runtime version), and
+inter-operate with old and new tanzu-plugin-runtime client APIs (through
+plugin). CLI Runtime library unifies both configuration files for end user
+interactions.
 
 ## Key Terms
 
@@ -16,7 +25,8 @@ Before tanzu-plugin-runtime version 0.28, CLI has only one configuration file wh
 
 `META` refers the metadata file at $HOME/.config/tanzu/config-metadata.yaml, it is hidden/dot file.
 
-CLI User should not manipulate any CLI configuration files directly, should interact only through CLI command line interface.
+CLI User should not manipulate any CLI configuration files directly, should
+interact only through CLI command line interface.
 
 ## Details
 
@@ -26,16 +36,17 @@ CLI User should not manipulate any CLI configuration files directly, should inte
 
 - In this proposal the overall state of the CLI configuration can conceptually be thought of as the union of two non-intersecting parts (CFG, CFG_NG) of the larger logical config file.
 
-- META: Over time, how the CLI interacts with the configuration can potentially evolve. This evolution will be triggered via a core CLI update, but has to be communicated to the plugins as well. This file, META (config-metadata.yaml a hidden/dot file, ) will serve the role of capturing this information. The file is not expected to be manipulated by the CLI user.
-  Ex: When in the future if configMetadata.settings.useUnifiedConfig is set to true by the future version of cli previously existing clis will read this data to use the new CFG_NG completely for all the data and CFG is no longer used.
+- META: Over time, how the CLI interacts with the configuration can potentially evolve. This evolution will be triggered via a core CLI update, but has to be communicated to the plugins as well. This file, META (config-metadata.yaml a hidden/dot file), will serve the role of capturing this information. The file is not expected to be manipulated by the CLI user. For instance, when in the future if configMetadata.settings.useUnifiedConfig is set to true by the future version of cli previously existing clis will read this data to use the new CFG_NG completely for all the data and CFG is no longer used.
 
 - Aspects of this proposal that plans to leverage META are:
 
 - Configuration of the patch policy for different parts of the configuration.
 
 - Determining when to transition to using a single configuration file (CFG_NG) to persist configuration state
 
-Note: due to the fact that information in the CFG_NG file directly affects the manipulation of the actual configuration files, it is not practical to embed said information in the files being manipulated
+Note: due to the fact that information in the CFG_NG file directly affects the
+manipulation of the actual configuration files, it is not practical to embed
+said information in the files being manipulated.
 
 ### Available Runtime Config APIs