docs: update contribution guidelines

refs #1080

docs/dev/explanation/FLOAT-FUSING.md

@@ -31,7 +31,7 @@ The float subgraph that was detected:
 
 ![](../../_static/float_fusing_example/subgraph.png)
 
-The simplified graph of operations with the float subgraph condensed in an `GenericFunction` node:
+The simplified graph of operations with the float subgraph condensed in a `GenericFunction` node:
 
 ![](../../_static/float_fusing_example/after.png)
 
@@ -39,7 +39,35 @@ The simplified graph of operations with the float subgraph condensed in an `Gene
 
 The first step consists in detecting where we go from floating point computation back to integers. This allows to identify the potential terminal node of the float subgraph we are going to fuse.
 
-From the terminal node, we go back up through the nodes until we find nodes that go from integers to floats. If we find a single node then we have a fusable subgraph we can replace it by an equivalent GenericFunction node. If we find more than one such node we try to find a single common ancestor that would go from integers to floats. We repeat the process as long as there are potential ancestors nodes, stopping if we find a suitable float subgraph with a single integer input and a single integer output.
+From the terminal node, we go back up through the nodes until we find nodes that go from integers to floats. If we find a single node then we have a fusable subgraph that we replace by an equivalent GenericFunction node and stop the search for fusable subgraphs for the terminal node being considered. If we find more than one such node we try to find a single common ancestor that would go from integers to floats. We repeat the process as long as there are potential ancestors nodes, stopping if we find a suitable float subgraph with a single integer input and a single integer output.
+
+Here is an example benefiting from the expanded search:
+
+<!--python-test:skip-->
+```python
+def fusable_with_bigger_search(x, y):
+    """fusable with bigger search"""
+    x = x + 1
+    x_1 = x.astype(numpy.int32)
+    x_1 = x_1 + 1.5
+    x_2 = x.astype(numpy.int32)
+    x_2 = x_2 + 3.4
+    add = x_1 + x_2
+    add_int = add.astype(numpy.int32)
+    return add_int + y
+```
+
+The `fusable_with_bigger_search` graph of operations:
+
+![](../../_static/float_fusing_example/before_bigger_search.png)
+
+The float subgraph that was detected:
+
+![](../../_static/float_fusing_example/subgraph_bigger_search.png)
+
+The simplified graph of operations with the float subgraph condensed in a `GenericFunction` node:
+
+![](../../_static/float_fusing_example/after_bigger_search.png)
 
 An example of a non fusable computation with that technique is:
 

docs/dev/howto/CONTRIBUTING.md

@@ -32,11 +32,10 @@ git checkout -b fix/tracing_indexing_42
 
 ### Conformance
 
-Each commit to **concretefhe**  should be conformant to the standards decided by the team. Conformance can be checked using the following commands.
+Each commit to **concretefhe**  should be conformant to the standards decided by the team. Conformance can be checked using the following command.
 
 ```shell
 make pcc
-make pytest
 ```
 
 ### pytest
@@ -49,28 +48,18 @@ make pytest
 
 ### Coverage
 
-The last requirement is to make sure you get a hundred percent code coverage. You can verify this using the following command (after having done `make pytest`).
-
-```shell
-make coverage
-```
-
-```{warning}
-FIXME(arthur): is this still valid? (that `make pytest` will not return an error)
-```
-
-Remark that only calling `make pytest` will give you information about the coverage, at the end of the execution, but the test will not return a failure if the coverage is not a hundred percent, as opposed to a call to `make coverage`.
-
-Note that this will compare the coverage with `origin/main`. If you want to set a custom base branch, you can specify `BB` environment variable like so `BB=$YOUR_BASE_BRANCH make coverage`.
+The last requirement is to make sure you get a hundred percent code coverage. The `make pytest` command checks that by default and will fail with a coverage report at the end should some lines of your code not be executed during testing.
 
 If your coverage is below hundred percent, you should write more tests and then create the pull request. If you ignore this warning and create the PR, GitHub actions will fail and your PR will not be merged anyway.
 
+There may be cases where covering you code is not possible (exception that cannot be triggered in normal execution circumstances), in those cases you may be allowed to disable coverage for some specific lines. This should be the exception rather than the rule and reviewers will ask why some lines are not covered and if it appears they can be covered then the PR won't be accepted in that state.
+
 ## Commiting
 
-We are using a consistent commit naming scheme, and you are expected to follow it as well. Here is the format and some examples.
+We are using a consistent commit naming scheme, and you are expected to follow it as well (the CI will make sure you do). The accepted format can be printed to your terminal by running:
 
 ```shell
-git commit -m "{feat|fix|refactor|test|benchmark|doc|style|chore}{($location)}?: description of the change"
+make show_scope
 ```
 
 e.g.
@@ -89,7 +78,7 @@ To learn more about conventional commits, check [this](https://www.conventionalc
 We remind that only official contributors can send pull requests. To become such an official contributor, please email hello@zama.ai.
 ```
 
-You should rebase on top of `main` branch before you create your pull request. This is to avoid merge commits and have a clean git log. After you commit your changes to your new branch, you can use the following commands to rebase.
+You should rebase on top of `main` branch before you create your pull request. We don't allow merge commits so rebasing on `main` before pushing gives you the best chance of avoiding having to rewrite parts of your PR later if some conflicts arise with other PRs being merged. After you commit your changes to your new branch, you can use the following commands to rebase:
 
 ```shell
 # fetch the list of active remote branches
@@ -107,6 +96,10 @@ git checkout $YOUR_BRANCH
 # rebase on top of main branch
 git rebase main
 
+# If there are conflicts during the rebase, resolve them
+# and continue the rebase with the following command
+git rebase --continue
+
 # push the latest version of the local branch to remote
 git push --force
 ```