Update COMMITTERS.adoc with current process

COMMITTERS.adoc

@@ -27,8 +27,8 @@ and you might merge more PRs from others than your own work.
 
 While not absolute, here is some advice:
 
-* If you really want a review by a specific person, make it a named reviewer via GitHub's "Reviewers" UI
-* If someone asked for a specific reviewer, better give some time for this person to review the PR.
+* If you really want a review from a specific person, make it a named reviewer via GitHub's "Reviewers" feature
+* If someone asked for a specific reviewer, better give some time to this person to review the PR.
   If not reviewed in a reasonable amount of time, better ping them again to have some information
   or ask the original author if we should go ahead.
 * If in doubt (on a specific part or because you're not comfortable reviewing documentation or any other reason),
@@ -37,23 +37,26 @@ While not absolute, here is some advice:
   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,
@@ -70,7 +73,7 @@ There are a few things you can do to help us be on schedule:
   That means:
 +
   ** Your PR needs to be created, obviously.
-  ** It should be reviewed by someone familiar with this area.
+  ** It should have been reviewed by someone familiar with this area.
   ** You have to take this feedback into account.
   ** And once approved, the PR can be merged.
   ** Also, keep in mind that we have a 3 hours CI cycle and CI needs to be green before any inclusion.
@@ -93,11 +96,13 @@ Quarkus depends on a lot of third party dependencies that we try to keep up to d
 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.
+Good examples would be Netty, 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.
+And, in any case, we should avoid upgrading these dependencies after the CR1 when we can.
 
+[[backward-compatibility]]
 == Backward Compatibility
 
 Quarkus evolves very fast and we decided we could break backward compatibility as long as:
@@ -107,9 +112,12 @@ Quarkus evolves very fast and we decided we could break backward compatibility a
   be it in terms of development time or added complexity.
 
 Usually, it is a good idea to have the opinion of people involved in the development of this area.
-And for widely used extensions or core changes, sending an email on the `quarkus-dev` mailing list
+And for widely used extensions or core changes, sending an email to the `quarkus-dev` mailing list
 should be considered.
 
+When deprecating things, make sure to keep the deprecations for 12 months,
+except you have a very good reason not doing so (and in this case, let's discuss it on quarkus-dev).
+
 Breaking changes should be marked with the `release/breaking-change` label and,
 if they need to be included in the release notes and/or announcement blog post,
 they should also be labelled with `release/noteworthy-feature`.
@@ -172,30 +180,23 @@ GitHub won't detect issues properly if you do something like
 == Affecting Labels and Milestones
 
 Affecting labels and milestones is very important in our process.
+The Quarkus Bot does it in most cases.
 
-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:
+In some cases, you might have to add some manually though:
 
-* 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.
+* 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.
+  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
 
 When we release a new version of Quarkus, we usually do a bugfix
 release a couple of weeks after.
 
-Every time we do a major release (e.g. `1.7.0.Final`), we create a release branch (e.g. `1.7`) to host
+Every time we do a major release (e.g. `2.7.0.Final`), we create a release branch (e.g. `2.7`) to host
 the commits for these bugfix releases.
 
 All the pull requests are merged in the `main` branch so they are applied to the new feature 
@@ -229,11 +230,11 @@ when we prepare the next bugfix release.
 
 == 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 :).