docs: adjust review time expectations

Author: dimas-b

CONTRIBUTING.md

@@ -142,5 +142,5 @@ To ensure smooth collaboration and to maintain a high-quality codebase, please a
 * `git log` can help you find the original/relevant authors of the code you are modifying. If you need, feel free to tag the author in your Pull Request comment if you need assistance or review.
 * Do not re-create a pull-request for the same change. Use one Pull Request related to the same change(s). The purpose here is to keep the history and all comments in the Pull Request.
 * Consider open questions and concerns in all comments of your Pull Request, provide replies and resolve addressed comments, if those don't serve reference purposes. If a comment doesn't contain `nit`, `minor`, or `not a blocker` mention, please provide feedback to the comment before merging.
-* Give time for review. For instance two working days is a good base to get first reviews and comments.
+* Give time for review. For instance two working days is a good base to get first reviews and comments for changes that are not likely to affect downstream projects. For changes that touch core interfaces and behaviours three working days would be advisable.
 * If you have the feeling that the discussions in a Pull Request are not going to a consensus, feel free to bring the discussion on the dev mailing list.