Update the contributing docs to include a policy on formatting changes.

This updates the contributing docs to highlight that Numba's policy
on large scale formatting changes is to not accept such patches.
It removes the fix a file to be flake8 compliant suggestion and
adds a link to the time boxed tasks available on the self-service
board.

CONTRIBUTING.md

@@ -21,9 +21,6 @@ changes, see **contributing patches** below.
 * Review a page of documentation, check it makes sense, that it's clear and
   still relevant, that the examples are present, good and working. Fix anything
   that needs updating in a pull request.
-* Make a file that is not `flake8` compliant meet the standard, a list of all
-  failing files is in the `exclude` section of the [`.flake8` config](https://github.com/numba/numba/blob/main/.flake8),
-  then create a pull request with the change.
 
 ## More involved things:
 
@@ -33,7 +30,8 @@ changes, see **contributing patches** below.
   documented, efficient and clear. Further, if the code is fixing a bug, making
   sure that tests are present demonstrating it is fixed! Look out for PRs with
   the [`needs initial review`](https://github.com/numba/numba/labels/needs%20initial%20review)
-  label.
+  label. There are also time boxed tasks available on the
+  [contributor self-service board](https://github.com/orgs/numba/projects/7).
 * Work on fixing or implementing something in the code base, there are a lot of
   [`good first issue's`](https://github.com/numba/numba/labels/good%20first%20issue)
   and [`good second issue's`](https://github.com/numba/numba/labels/good%20first%20issue).

docs/source/developer/contributing.rst

@@ -252,6 +252,25 @@ A code review should try to assess the following criteria:
 * docstrings, comments
 * test coverage
 
+
+Policy on large scale changes to code formatting
+''''''''''''''''''''''''''''''''''''''''''''''''
+
+Please note that pull requests making large scale changes to format the code
+base are in general not accepted. Such changes often increase the likelihood of
+merge conflicts for other pull requests, which inevitably take time and
+resources to resolve. They also require a lot of effort to check as Numba aims
+to compile code that is valid even if it is not ideal, i.e. testing
+``operator.eq``::
+
+    if x == None: # should be `if x is None:` but it's valid so don't change it!
+
+This policy has been adopted by the core developers so as to try and make best
+use of limited resources. Whilst it would be great to have an extremely tidy
+code base, priority is given to fixes and features over code formatting changes.
+Thanks for your understanding on this matter!
+
+
 Coding conventions
 ''''''''''''''''''