fixup! CONTRIBUTING.md: Add "General Tips" section

Make it more prominent

Author: miri64

CONTRIBUTING.md

@@ -31,6 +31,27 @@ If you are just beginning to work with RIOT you might first want to read our
 
 [documentation]: https://doc.riot-os.org
 
+## General Tips
+[general-tips]: #general-tips
+From experience, the following recommendations help to get a software
+contribution into RIOT master faster:
+
+- **Ask around for help!** Either offline or through one of our communication
+  channels (see above). The earlier you check your feature design with other
+  people, the less likely it is that it is denied during the review process.
+- **Verify your concept early!** If you work on your own until the code
+  *looks* good enough to show publicly, you might miss some design flaws others
+  might have spotted earlier.
+- **Keep it simple!** Try to use what is already there and don't change existing
+  APIs if not absolutely necessary.
+- **Keep it small!** A PR with >1000 lines of changes will very likely make
+  even the most active reviewer put your review on their long to-do list.
+- **Keep it modular!** Make extensions to a feature or new features for a
+  platform optionally to use.
+- **Provide tests!** They should be comprehensible and easy to be executed.
+  Alternatively comprehensive testing procedures should be provided with your
+  pull request.
+
 ## Help Wanted
 [help-wanted]: #help-wanted
 In case you're not really sure where to start, we've created a list of suggestions.
@@ -96,27 +117,6 @@ and got no response.
 [labels]: https://github.com/RIOT-OS/RIOT/wiki/RIOT%27s-labeling-system
 [open-a-pull-request]: https://help.github.com/articles/using-pull-requests
 
-## General Tips
-[general-tips]: #general-tips
-From experience, the following recommendations help to get a software
-contribution into RIOT master faster:
-
-- **Ask around for help!** Either offline or through one of our communication
-  channels (see above). The earlier you check your feature design with other
-  people, the less likely it is that it is denied during the review process.
-- **Verify your concept early!** If you work on your own until the code
-  *looks* good enough to show publicly, you might miss some design flaws others
-  might have spotted earlier.
-- **Keep it simple!** Try to use what is already there and don't change existing
-  APIs if not absolutely necessary.
-- **Keep it small!** A PR with >1000 lines of changes will very likely make
-  even the most active reviewer put your review on their long to-do list.
-- **Opt-in is better than mandatory!** Make extensions to a feature or new
-  features for a platform optionally to use.
-- **Provide tests!** They should be comprehensible and easy to be executed.
-  Alternatively comprehensive testing procedures should be provided with your
-  pull request.
-
 ## Feature Requests
 [feature-requests]: #feature-requests