anchor.diff:  
   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.
  
positive.code: * 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.
  Make sure to add a comment explaining why it was put on hold.
  
  ==== Step 3: Marking for merge
  
negative.code: === 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 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.
  