anchor.diff:  
   == Good First Issues
   
  -We need to find the right balance between fixing the issue right away
  +We need to find the right balance between fixing the issues right away
   and trying to onboard new contributors.
   
  -It's not always easy to find one, but if you think the issue is appropriate,
  -affecting it the `good first issue` label for some time might be a good thing.
  +It's not always easy to find one, but if you think an issue is appropriate,
  +affecting the `good first issue` label to it for some time might be a good thing.
   
   Obviously, critical bugs are not good candidates :).
   
  
positive.code: == Affecting Labels and Milestones
  
  Affecting labels and milestones is very important in our process.
  
  Before each release, we check that we don't have any
  closed issues that don't have either a milestone affected or
  some of the "excluding" labels.
  
  Thus:
  
  * If you close a pull request because the committers have decided to not merge it,
    please add the appropriate `triage/` label: `triage/invalid`, `triage/out-of-date`,
    `triage/wontfix` are usually in order.
  * If you close an issue because it has been fixed, either add the milestone
    if you can find it easily or use the `triage/out-of-date` if you can't.
  * If you close an issue for any other reason, one of the aforementioned `triage/` labels
    is probably adequate.
  * 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.
  
  [[backporting-process]]
  == Backporting Process
  
negative.code:   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 (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 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,
  