Made the contributing policy more clear

Author: AlexandreRouma

.github/pull_request_template.md

@@ -1,7 +1,4 @@
 # Important
 
-Only minor bug fixes and bandplans are accepted.
-
-Pull requests adding features or any bug fix that requires significant code changes will be automatically rejected.
-
+Only bandplan, colormaps and themes are accepted. Code pull requests are **NOT welcome**. 
 Open an issue requesting a feature or discussing a possible bugfix instead.

contributing.md

@@ -1,65 +1,6 @@
 # Pull Requests
 
-**I DO NOT ACCEPT PULL-REQUEST FOR FEATURES OR BUGFIXES REQUIRING SIGNIFICANT CODE/STRUCTURE CHANGES.**
-**SUCH PULL REQUESTS WILL BE CLOSED AUTOMATICALLY. OPEN AN ISSUE DETAILING FEATURE REQUESTS OR POTENTIAL BUGFIX INSTEAD.**
-
-# Code Style
-
-## Naming Convention
-
-- Files: `snake_case.h` `snake_case.cpp`
-- Namespaces: `CamelCase`
-- Classes: `CamelCase`
-- Structs: `CamelCase_t`
-- Members: `camelCase`
-- Enum: `SNAKE_CASE`
-- Macros: `SNAKE_CASE`
-
-## Brace Style
-
-```c++
-int myFunction() {
-    if (shortIf) { shortFunctionName(); }
-
-    if (longIf) {
-        longFunction();
-        otherStuff();
-        myLongFunction();
-    }
-}
-```
-
-Note: If it makes the code cleaner, remember to use the `?` keyword instead of a `if else` statement.
-
-## Pointers
-
-Please use `type* name` for pointers.
-
-## Structure
-
-Headers and their associated C++ files shall be in the same directory. All headers must use `#pragma once` instead of other include guards. Only include files in a header that are being used in that header. Include the rest in the associated C++ file.
-
-# Modules
-
-## Module Naming Convention
-
-All modules names must be `snake_case`. If the module is a source, it must end with `_source`. If it is a sink, it must end with `_sink`.
-
-For example, lets take the module named `cool_source`:
-
-- Directory: `cool_source`
-- Class: `CoolSourceModule`
-- Binary: `cool_source.<os dynlib extension>`
-
-## Integration into main repository
-
-If the module meets the code quality requirements, it may be added to the official repository. A module that doesn't require any external dependencies that the core doesn't already use may be enabled for build by default. Otherwise, they must be disabled for build by default with a `OPT_BUILD_MODULE_NAME` variable set to `OFF`.
-
-# JSON Formatting
-
-The ability to add new radio band allocation identifiers and color maps relies on JSON files. Proper formatting of these JSON files is important for reference and readability. The following guides will show you how to properly format the JSON files for their respective uses.
-
-**IMPORTANT: JSON File cannot contain comments, there are only in this example for clarity**
+Code pull requests are **NOT welcome**. Please open an issue discussing potential bugfixes or feature requests instead.
 
 ## Band Frequency Allocation 
 
@@ -119,8 +60,8 @@ Please follow this guide to properly format the JSON files for custom color maps
 }
 ```
 
-# Best Practices
+# JSON Formatting
+
+The ability to add new radio band allocation identifiers and color maps relies on JSON files. Proper formatting of these JSON files is important for reference and readability. The following guides will show you how to properly format the JSON files for their respective uses.
 
-* All additions and/or bug fixes to the core must not add additional dependencies.
-* Use VSCode for development, VS seems to cause issues.
-* DO NOT use libboost for any code meant for this repository
+**IMPORTANT: JSON File cannot contain comments, there are only in this example for clarity**