grammar fixes

Signed-off-by: Luke Reed <[email protected]>

hips/hip-9999.md

@@ -1,6 +1,6 @@
 ---
 hip: 9999
-title: "Add Repository URL and tarball digest to a charts release metadata"
+title: "Add Repository URL and tarball digest to a chart's release metadata"
 authors: [ "Luke Reed <[email protected]>" ]
 created: "2021-11-24"
 type: "feature"
@@ -9,15 +9,15 @@ status: "draft"
 
 ## Abstract
 
-Currently there is no way of knowing the exact repository that a chart originated from for a given release. There are ways to guess by looking at the sources list in the chart metadata, but since this is provided via the `Chart.yaml` file, any forks of that repository will look identical. The only way to concretely know what the repository URL is that was used at install/upgrade time is to populate a repository URL metadata field in the release during the install or upgrade. It should work for both traditional repositories behind an http web server, as well as an OCI compliant repository.
+Currently there is no way of knowing the exact repository that a chart originated from for a given release. There are ways to guess by looking at the sources list in the chart metadata, but since this is provided via the `Chart.yaml` file, any forks of that repository will look identical. The only way to concretely know what the repository URL that was used at install/upgrade time is to populate a repository URL metadata field in the release during the install or upgrade. It should work for both traditional repositories behind an http web server, as well as an OCI compliant repository.
 
 The second part of this proposal would include the tarball digest of a chart in the metadata. This aspect is less fleshed out in code yet, but would be a nice alternative for installing a local chart from a tarball when the repository URL would not be known. The reason this is useful is because it can be used when interacting with other third-party databases, such as artifact-hub.
 
 ## Motivation
 
 The primary motivation is to have a helm-native way to track where a chart came from. Many of the motivations for this feature can be found in this issue: https://github.com/helm/helm/issues/4256. To note a couple:
 - An admin would like to know where a chart came from only by querying the cluster itself. Currently the only way to know where a chart came from is to keep track of it externally.
-- Third-party tooling to that provides recommendations on helm upgrades can query the cluster to get the repository URL to aid in this recommendation. See [nova](https://github.com/FairwindsOps/nova) as an example.
+- Third-party tooling that provides recommendations on helm upgrades can query the cluster to get the repository URL to aid in this recommendation. See [nova](https://github.com/FairwindsOps/nova) as an example.
 - This metadata field could also populate output for the `helm ls` command in the future. That may be outside the scope of this particular feature.
 
 ## Rationale
@@ -28,7 +28,7 @@ In order to query for this in the cluster, the repository URL will need to be so
 
 Nothing would change from the user's perspective. With some modifications in the current code it's possible to add this metadata into the release object transparently.
 
-The current idea for this implementation is to add a field in both the `ChartDownloader` and `Metadata` (in the `pkg/chart/metadata.go` file) structs to hold the repository URL. The Downloader is the logical place to derive the proper URL and can then that storage location can populate the Metadata field.
+The current idea for this implementation is to add a field in both the `ChartDownloader` and `Metadata` (in the `pkg/chart/metadata.go` file) structs to hold the repository URL. The Downloader is the logical place to derive the proper URL and then populate the Metadata field.
 
 More specifically, the URL is included in the local repository index file for a locally named repository. For instance, running `helm repo add [NAME] [URL]` would add the repository to the index file with the `[URL]` passed as the real location to download charts. In the helm code, the downloader reads this file to find the URL which is what gets bubbled up to the release object.