more sme feedback

Author: otikhomi

docs/modules/ROOT/pages/how-to-guides/proc_upgrade_build_pipeline.adoc

@@ -64,14 +64,14 @@ To further reinforce the security of your custom build pipeline, complete the fo
 
 * Add an `OWNERS` file to the root of your repository and list trusted contributors there.
 ** To learn more, see Kubernetes docs about link:https://www.kubernetes.dev/docs/guide/owners/[OWNERS files].
-* Avoid commenting `/ok-to-test` on pull requests from untrusted authors, review such PRs carefully first. The `/ok-to-test` comment runs the PipelineRun, and malicious code in a PR can change your build and compromise the security of your application.
+* Review all pull requests carefully. Avoid commenting `/ok-to-test` on PRs from untrusted authors. The `/ok-to-test` comment runs the PipelineRun, and malicious code in a PR can change your build and compromise the security of your application.
 ** To learn more about running the PipelineRun, see the link:https://pipelinesascode.com/docs/guide/running/#running-the-pipelinerun[Running the PipelineRun guide] from Pipelines as Code docs. 
 * Consider changing the PipelineRun definition source by setting the `pipelinerun_provenance` setting to `default_branch`. With this setting, Pipelines as Code uses the PipelineRun definition from the default branch of the repository, usually `main` or `master`, and only contributors with default branch merge rights can modify the PipelineRun.
 +
-If you don’t set `pipelinerun_provenance`, you allow the default behaviour: the PipelineRun definition is fetched from the branch where the PipelineRun event is triggered, and any contributor can get access to the PipelineRun definition.
+If you don’t set `pipelinerun_provenance`, you allow the default behavior: the PipelineRun definition is fetched from the branch where the PipelineRun event is triggered, and link:https://pipelinesascode.com/docs/guide/running/[submitters who are allowed to run a PipelineRun] can get access to the PipelineRun definition.  External submitters cannot run a PipelineRun and need a repository owner to comment `/ok-to-test` on a PR. In these cases `pipelinerun_provenance: default_branch` still applies, and the PipelineRun definition is taken from the default branch.  
 +
-Testing changes to the PipelineRun is easier with the default behaviour because PipelineRun changes are tested when a user submits a pull request, before the merge.
+Testing changes to the PipelineRun is easier with the default behavior because PipelineRun changes are tested when a user submits a pull request, before the merge.
 +
-Setting the `pipelinerun_provenance` setting to `default_branch` is more cautious because a PipelineRun definition is tested only after a repository owner reviews and merges it. However, if the proposed change doesn't work correctly, a repository owner might need to merge a few changes to debug the PipelineRun.
+Setting the `pipelinerun_provenance` setting to `default_branch` is more cautious because PipelineRun changes are tested only after a repository owner reviews and merges them. We recommend that repository owners review all changes to PipelineRun very carefully before the merge. If the proposed change doesn't work correctly, a repository owner might need to merge a few changes to debug the PipelineRun.
 
 ** To learn more about setting the PipelineRun definition source, see link:https://pipelinesascode.com/docs/guide/repositorycrd/#pipelinerun-definition-provenance[PipelineRun definition provenance].