anchor.diff:    look if interested.
     If the PR is very large or is a new extension, better let it
     bake for a few days.
  -* We do merge commits so please ask the author to properly squash the commits before merging.
  -  The idea is to have proper semantic commits.
  +* We do _merge commits_ so please ask the author to properly squash the commits before merging (when it makes sense).
  +  The idea is to have proper semantic commits. Several commits is not a problem as long as they have a proper semantic.
     If the author is not familiar with Git or not available, you can also (carefully)
     https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork[do it for them]
     as long as you both agreed on it.
   * Make sure the commit comments are meaningful.
   * As a new committer, you can start by giving your approval and not merging and see how things evolve.
  -  This should give you some hints of important things to check in the future.
  -* Only merge pull requests that target main.
  -  **Dealing with old branches is a separate process.**
  +  This should give you some hints on important things to check in the future.
  +* Only merge pull requests that target `main`.
  +  **Dealing with older branches is a separate process.**
   * If you are sure a PR should go in and is just waiting for CI,
     just use the `triage/waiting-for-ci` label.
     It is a good hint for other committers.
   * If you think a pull request is an essential part of a given milestone (and can realistically be a part of it),
     you should affect this milestone to it so that we can be sure it stays on the radar.
  +  Otherwise, better not do it and let the Quarkus bot do it for you.
   * If you think a pull request is worth mentioning in the release notes and/or
     the announcement blog post, add the `release/noteworthy-feature` label.
  +* If you think a pull request introduces some breaking changes,
  +  add the `release/breaking-change` label, see <<backward-compatibility,Backward Compatibility>> for more details.
   * Do NOT affect a PR to an old branch, see the <<backporting-process,backporting process>> for more details.
   
   Obviously, each situation is different so use your own judgement,
  
positive.code: We partially rely on Dependabot for https://github.com/quarkusio/quarkus/blob/main/.github/dependabot.yml[a curated list of dependencies].
  
  Some dependencies are critical for Quarkus and quite complex.
  Good examples would be Vert.x or Hibernate ORM.
  
  It is good practice to update these core dependencies at the beginning of a given
  release cycle to let them time to bake in the main branch before being released.
  
  == Backward Compatibility
  
  Quarkus evolves very fast and we decided we could break backward compatibility as long as:
  
negative.code: == Affecting Labels and Milestones
  
  Affecting labels and milestones is very important in our process.
  The Quarkus Bot does it in most cases.
  
  In some cases, you might have to add some manually though:
  
  * If you close an issue that has not been closed automatically, either affect a milestone if it has been fixed
    or one of the `triage/invalid`, `triage/out-of-date`, `triage/wontfix` labels if not.
  * Some issues are created as `kind/bug` but are more support questions:
    in this case, remove the `kind/bug` label and add the `kind/question` label
    or even better redirect them to the Discussions section.
  
  [[backporting-process]]
  == Backporting Process
  