Richard Edgar

Based on the discussion in the community call, I'm happy with the following being done: 1. Renaming `metric` to `metrics` in the argument list 2. Switching to keyword arguments 3....

I'm not keen on allowing `None` for `y_true` and `y_pred`; not until we're really sure we want to expand on `MetricFrame` in this way. Otherwise, I'm OK with those two...

Hmmm.... good point.

I'm still not enamoured of accepting `**kwargs` in a function signature. It means that if we *ever* want to add new arguments to the signature, we're going to break someone....

I'd say "Alternative A with `y_true` and `y_pred` as required arguments."

The only workaround required now would be to supply a 'dummy' column for one or the other. Obviously making them optional doesn't break anything which works now doesn't break anything...

I believe that this is a reasonably coherent set of content, even though more would be welcome.

Adding an informational note.... this PR is not going to be merged, but I would like to keep it around because I think that parts of the text will be...

I have a repro written as a test case, and [parameterised with both learners and moments](https://github.com/riedgar-ms/fairlearn/blob/riedgar-ms/pickle-expgrad-test/test/unit/reductions/exponentiated_gradient/test_exponentiatedgradient_pickle.py). I agree that this appears to be related to what the `_Lagrangian` is doing,...

Having re-read the existing documentation, and also seen the incoming PR #1111 from @alliesaizan , I propose the following... First, I think that we need two user guide pages. The...