anchor.diff:  and we do not enforce a single code style across the codebase at the moment.
   
   * New code should follow the (majority) style guide.
  -  In Jenkins core we use the link:https://www.oracle.com/java/technologies/javase/codeconventions-contents.html[these Code Conventions for the Java TM Programming Language] as a default code style
  +  In Jenkins core, we use link:https://www.oracle.com/java/technologies/javase/codeconventions-contents.html[these Code Conventions for the Java TM Programming Language] as a default code style
   * Updates to existing code should only fix formatting on the lines affected anyway to keep the diff minimal.
     It helps reviewers focus their attention on the specifics of the change and reduces the risk of a change from one pull request creating a conflict in another pull request.
   
   ==== Maintaining documentation
   
   * Jenkins documentation is hosted on https://www.jenkins.io/doc/.
  -  When a new user-facing change is added, we should encourage contributors to update documentation in downstream pull requests.
  -* Same applies to Jenkins changelogs (link:https://www.jenkins.io/changelog[weekly], link:https://www.jenkins.io/changelog-stable/[stable]) and link:https://www.jenkins.io/doc/upgrade-guide/[upgrade guidelines]:
  -  We have a semi-automated process which is based on pull request summaries and labels.
  +  When a new user-facing change is added, we should encourage contributors to update the documentation in downstream pull requests.
  +* The Same applies to Jenkins changelogs (link:https://www.jenkins.io/changelog[weekly], link:https://www.jenkins.io/changelog-stable/[stable]) and link:https://www.jenkins.io/doc/upgrade-guide/[upgrade guidelines]:
  +  We have a semi-automated process that is based on pull request summaries and labels.
     Core maintainers are expected to validate the entries as a part of the pull request review/merge process.
     See the checklist below in the _Merge process_ section.
   
  
positive.code: === Ladder
  
  * **Contributors**. Anyone can participate.
    There is no precondition except having a GitHub account, just submit pull requests or comment in existing ones!
  * **Core Pull Request Reviewers** can be nominated by contributors in the link:https://groups.google.com/d/forum/jenkinsci-dev[developer mailing list]. 
  Self-nomination is fine.
  Decision is made by a consensus in the mailing list or via voting at the link:https://www.jenkins.io/project/governance-meeting/[governance meeting].
  * **Core Maintainers** - same process as for Core PR reviewers.
    All nominees must also sign an link:https://github.com/jenkinsci/infra-cla/[Individual Contributor License Agreement] before getting the permission in GitHub repositories.
  * **Release Team Members** are assigned by the Jenkins Release officer
  
  == Pull request review process
  
negative.code: 
  Pull requests review in Jenkins is not just about reviewing code and accepting them if the code is OK.
  Core maintainers are expected to ensure feasibility and compatibility of changes,
  to maintain a good quality of the codebase and documentation,
  and to ensure there is a consensus between contributors.
  
  ==== Verifying Feasibility
  
  Reviewers are expected to look at changes critically from a "product management" point of view.
  It's not just about the code, but also whether the change makes sense in a global/holistic way, considering existing popular plugins and the way users experience Jenkins overall.
  Also, not every change needs to be merged into the core.
  Many features would be better introduced as plugins that have separate release cycles and allow delivering changes faster.
  We want to extend the Jenkins core and incorporate widely used functionality and extension points there,
  but we try to keep the core as minimal as possible in terms of dependencies.
  
  