message: More changes to contributing.md
diff: @@ -21,7 +21,8 @@ This project and everyone participating in it is governed by a [Code of Conduct]
  * When maintaining a branch, merge frequently with the master.
  * When maintaining a branch, submit pull requests to the master frequently.
  * If you are working on a bigger issue try to split it up into several smaller issues.
  -* Please do not use "Draft" pull requests, they clutter our world view. Rather, use issues to discuss whatever needs discussing.
  +* Please do not use "Draft" pull requests, they clutter our world view. Rather, use issues or discussion topics to discuss whatever needs discussing.
  +* We reserve full and final discretion over whether or not we will merge a pull request. Adhering to these guidelines is not a complete guarantee that your pull request will be merged.
  ## Building
  * To build the project, run `make`.
  @@ -29,12 +30,14 @@ This project and everyone participating in it is governed by a [Code of Conduct]
  * For parallel builds, you can use the [Ninja](https://ninja-build.org/) build system: `GEN=ninja make`.
  ## Testing
  +* Unit tests can be written either using the sqllogictest framework (`.test` files) or in C++ directly. We **strongly** prefer tests to be written using the sqllogictest framework. Only write tests in C++ if you absolutely need to (e.g. when testing concurrent connections or other exotic behavior).
  +* Documentation for the testing framework can be found [here](https://duckdb.org/docs/dev/testing).
  +* Write many tests.
  +* Test with different types, especially numerics, strings and complex nested types.
  +* Try to test unexpected/incorrect usage as well, instead of only the happy path.
  * `make unit` runs the **fast** unit tests (~one minute), `make allunit` runs **all** unit tests (~one hour).
  -* Make sure **all** unit tests pass before merging into the master branch.
  -* Write many tests
  -* Test with different types, especially numerics and strings
  -* Try to test unexpected/incorrect usage as well, instead of only the happy path
  -* Slower tests should be added to the **all** unit tests. You can do this by adding `[.]` after the test group. For an example see `test_tpch.cpp`.
  +* Make sure **all** unit tests pass before sending a PR.
  +* Slower tests should be added to the **all** unit tests. You can do this by naming the test file `.test_slow` in the sqllogictests, or by adding `[.]` after the test group in the C++ tests.
  * Look at the code coverage report of your branch and attempt to cover all code paths in the fast unit tests. Attempt to trigger exceptions as well. It is acceptable to have some exceptions not triggered (e.g. out of memory exceptions or type switch exceptions), but large branches of code should always be either covered or removed.
  ## Formatting
  @@ -75,6 +78,7 @@ private:
  ```
  * Avoid [unnamed magic numbers](https://en.wikipedia.org/wiki/Magic_number_(programming)). Instead, use named variables that are stored in a `constexpr`.
  * [Return early](https://medium.com/swlh/return-early-pattern-3d18a41bba8). Avoid deep nested branches.
  +* Do not include commented out code blocks in pull requests.
  ## Error Handling
  * Use exceptions **only** when an error is encountered that terminates a query (e.g. parser error, table not found). Exceptions should only be used for **exceptional** situations. For regular errors that do not break the execution flow (e.g. errors you **expect** might occur) use a return value instead.
  