anchor.diff:  * Conversations in the pull request are over OR it is explicit that a reviewer does not block the change (often indicated by line comments attached to an approving PR review, or by using the term "nit", from "nit-picking")
   * Changelog entries in the PR title and/or _Proposed changelog entries_ are correct and reflect the current, final state of the PR
   * Proper changelog labels are set so that the changelog can be generated automatically.
  - List of labels we use for changelog generation is available link:https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml[here].
  + A List of labels we use for changelog generation is available link:https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml[here].
   * If the change needs administrators to be aware of it when upgrading, the `upgrade-guide-needed` label is present
     and there is a `Proposed upgrade guidelines` section in the PR title
     (link:https://github.com/jenkinsci/jenkins/pull/4387[example]).
  -  This is usually the case when a data migration occurs, a feature has been removed, a significant behavior change is introduced (including when there is a way to opt out),
  +  This is usually the case when a data migration occurs, a feature has been removed, a significant behaviour change is introduced (including when there is a way to opt-out),
     or in general when we expect at least a large minority of admins to benefit from knowing about the change, e.g. to apply a new option.
  -* If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see link:https://issues.jenkins.io/issues/?filter=12146[this Jira query]).
  +* If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labelled as `lts-candidate` to be considered (see link:https://issues.jenkins.io/issues/?filter=12146[this Jira query]).
   
   ==== Step 2: Is it a good time to merge?
   
  
positive.code: Special permissions are not required to take this role or to contribute.
  Anyone is welcome to start contributing (see the <<issue-triage,triage guidelines below>>).
  
  **Core Pull Request Reviewers** is a team for contributors who are willing to regularly review Jenkins pull requests and to eventually become Jenkins core maintainers.
  They get https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization[Triage permissions] so that they can manage pull requests, request reviews and prepare changelog drafts in the pull request description.
  Their main responsibility is to triage and review the incoming pull requests
  and to guide newcomer contributors who are not familiar with the project's processes.
  
negative.code: === Ladder
  
  * **Contributors**. Anyone can participate.
    There is no precondition except having a GitHub account, just submit pull requests or comment on 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.
  The 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 permission in GitHub repositories.
  * **Release Team Members** are assigned by the Jenkins Release officer
  
  == Pull request review process
  