Pydocstyle's suggestions seem irrelevant in these cases to me.

1. Should I add docstring to these 3 methods?

   line 47 in public method fit: D102: Missing docstring in public method

   line 57 in public method transform: D102: Missing docstring in public method

   line 63 in public method inverse_transform: D102: Missing docstring in public method

2. And I'm still not sure about _eval_pearsonr:

   sktime/transformations/series/boxcox.py:114 in private nested function _eval_pearsonr: D205: 1 blank line required between summary line and description (found 0)

   sktime/transformations/series/boxcox.py:114 in private nested function _eval_pearsonr: D400: First line should end with a period (not 't')

3. What to do generally? Just follow the pydocstyle (because if anybody changes this file in the future will get the same code-check error)? Asking core contributors every time doesn't seem like a good idea 🤔

Hi @GuzalBulatova,

1. Yes, please add a docstring for those methods, I fixed the docstrings in this file: https://github.com/alan-turing-institute/sktime/blob/main/sktime/transformations/series/acf.py - that should help you to fill in the docstrings for fit, transform and inverse_transform
2. Seems like you can either remove the docstring for private functions entirely or fix it (see http://www.pydocstyle.org/en/stable/error_codes.html#publicity)
3. Thanks for raising these questions, I feel that fixing the documentation is very important for us at this stage and that we can still achieve this through the automated CI checks but happy to discuss this again in a few weeks if it causes too much trouble!

Hi @mloning ! I've added docstrings to fit, transform and inverse_transform , thanks for the hint, it helped a lot.
I looked at the pydocstyle link you sent, thank you, it's a great resource! Removed docstr for _eval_pearsonr as it's not required for inside nested function.
I think now the PR is ready for review.