fairlearn
DOC Add versionadded and versionchanged to API reference (fairlearn.reductions)
Add versionadded and versionchanged to API reference of fairlearn.reductions. Sub-issue of #855.
Hi @romanlutz, after diving in to all the changes made in different versions, I am wondering what level of detail is expected in the versionchanged part of this issue.
To give an example of my doubts, consider the changed mentioned in the version guide related to ExponentGradient:
v0.4.5:
v0.4.6:
v0.5.0:
So my question is, should all these changes be included, and if not, how do I know which to include?
That's a great question! I'm actually not entirely sure. @fairlearn/fairlearn-maintainers wdyt? Have you tried out whether it's technically possible to add more than one versionchanged tag? If it's not possible then I suppose it has to be the changes in the latest version in which it was changed.
Whenever it is an individual argument you can add it just for that one, e.g., sample_weight_name was added in v0.5.0. max_iter, eta0, and run_linprog_step were also added in v0.5.0.
Turns out it is possible to include multiple versionchanged tags. So I'll try to add all mentioned changes.
I usually apply the tags only when a parameter changes behavior, or a major change in behavior is happening in a class. It's not supposed to mirror the changelog in any way IMO.
I agree. We've had some changes in the datasets module which @adrinjalali and I recommended omitting from versionchanged since only small changes or doc changes happened.
Example: from the above changes I'd definitely omit the one on pickle vs. clone (since it's internal). Several of the others are parameter renames or additions which should go directly on the parameter documentation.
So I made some first changes and to test I tried committing to my local fork. I'm not sure if I accidentally pushed it to the main branch, as I do not have any experience using GitHub with multiple people on the same project?
No worries! You can always check your branch with git status, ideally before pushing 🙂 If you pushed to main on your fork you can always copy those changes to another branch (by creating another branch off of your main, for example) and then git rebase -i HEAD~1 (or whatever number of commits you need to remove if larger than 1), then use drop to remove those commits. Pushing (perhaps with --force, not sure...) will erase the main changes. Feel free to message me on Discord if you need more help! In any case, your fork is your playground and there's nobody working there but you. It only gets interesting when you pull in changes from fairlearn/fairlearn ("the main repo"). Some of the instructions I wrote for our last sprint might be useful https://github.com/romanlutz/fairlearn-scipy-sprint. Again, don't worry if your setup is slightly different. Just reach out and we'll be happy to help!
If you like quick and frequent feedback you can open a "draft" PR and get our comments right away while at the same time making clear that your PR requires more work. The nice thing about that is that we won't be as nitpicky, but we'll point out issues early on so you might save yourself some time.
ExponentiatedGradient and GridSearch are done thanks to @bramreinders97! The other files under fairlearn.reductions remain, of course.