Fix few grammar and punctuation errors
@@ -100,7 +100,7 @@ but we try to keep the core as minimal as possible in terms of dependencies.
The Jenkins project has a long history of backward compatibility.
We accept breaking changes when it is needed (security fixes, feature deprecation and removal, etc.),
-but ultimately the project's goal is retain as much compatibility as possible.
+but ultimately the project's goal is to retain as much compatibility as possible.
It includes both feature compatibility and binary/API compatibility which is important for the plugin ecosystem.
Although we have some tools (like https://github.com/jenkins-infra/usage-in-plugins[usage-in-plugins]) for checking API usages across open-source plugins,
there is no way to confirm external usages in 3rd-party proprietary plugins which are also a part of the ecosystem.
@@ -281,7 +281,7 @@ In addition to the initial triage, it is a good practice to sometimes review pre
=== Triaging requests for enhancement
Requests for enhancement (RFEs) include the `New Feature` and `Improvement` types in Jenkins Jira.
-The process to triage them might be different than bug reports.
+The process to triage them might be different from bug reports.
because it is not always possible to say whether a request should be implemented in the Jenkins core,
an existing or a new plugin.
In the case of doubt, it is fine to just skip an issue or CC subject matter experts who could advice.
@@ -350,7 +350,7 @@ For these reasons, the following changes should not be merged during the week be
* Changes that could be considered risky (relatively high risk of introducing regressions), as they could make users of Jenkins weekly releases choose between getting security fixes, and having a functioning Jenkins
* Very large changes (in terms of lines changed), because the Jenkins security team needs to prepare security fixes for the weekly release line in a very short period of time.
-If the change is ready but it is not a good time, consider labeling the pull request with the `on-hold` label.
+If the change is ready, but it is not a good time, consider labeling the pull request with the `on-hold` label.
Make sure to add a comment explaining why it was put on hold.
==== Step 3: Marking for merge
