Guillaume Lemaitre

Basically the only thing is to expose the `adjusted` parameter. `True` will fall back to the previous implementation while `False` will not adjust for chance.

Would it make sense to have submodule? Like in xgboost where you have a different repository for the `core` library, etc.

You are right. Speaking with joris, the issue tracker and PRs handling would be rather complicated.

Technically, I would prefer to modify the `Workflow` and the cross-validation loop. I think that whenever possible it should fall-back on scikit-learn avoiding to reinvent the wheel. However, it would...

So I would not consider it a bug since there are no real "wrong" results. We could improve the consistency since that now: - Calling `roc_curve` and `ROCCurveDisplay` will not...

I would like to have some thoughts other core-devs before going forward. ping @Micky774 @thomasjpfan @adrinjalali @ogrisel

I put the following reference: https://arxiv.org/pdf/2009.11023.pdf I think that it would nice to put into perspective the three methods. > I'm fine with this, but I feel it's a bit...

There is also the SAGE (https://github.com/iancovert/sage) package building on SHAP that could be nice. However, I have to check the tutorial.

For me, I would be happy with merging the example with the current scope. We can later change the scope if we find new things to add regarding the other...

Uhm I am wondering if they did not make a refactoring because I don't see anymore `KernelExplainer` or `TreeExplainer`: https://shap.readthedocs.io/en/latest/api.html#explainers Instead it seems that you have a single class `Explainer`...