anchor.diff:    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,
  
positive.code: 
  == Good First Issues
  
  We need to find the right balance between fixing the issue 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.
  
  Obviously, critical bugs are not good candidates :).
  
  
negative.code: 
  While not absolute, here is some advice:
  
  * 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),
  