Documentation from API to User Guide

[gabrielapgomezji]

Describe the issue linked to the documentation

Reviewing the documentation of the functions, some of the descriptions are a bit long (for example joiner). It might be simpler to the user, when working with the functions, to have a brief description in the API and move the rest of the documentation to the User Guide. I noticed that the following functions had a long description and would benefit for a simplification:

• ToCategorical
• ToDatetime
• StringEncoder
• TextEncoder
• TableVectorizer
• tabular_learner
• DropUninformative
• Deferred
• eval_mode
• skrub.Expr.skb.full_report
• skrub.Expr.skb.get_pipeline
• skrub.Expr.skb.get_grid_search
• skrub.Expr.skb.mark_as_X
• skrub.Expr.skb.mark_as_y
• Column_associations

Also, I noticed that some didn't have a description (I don't know if it is intentional, if it's missing or it shouldn't be like that):

• Filter
• NameFilter
• Selector

Suggest a potential alternative/fix

No response

[rcap107]

Thanks @gabrielapgomezji for going over all the functions and noting down what needs fixing

We are thinking of moving most of the details from the start of the docstring to the appropriate section in the User guide, leaving only a short paragraph detailing what the object is doing. Additionally, some objects may need additional context on the implementation or use case, and that should be put in the notes section. It should be done on a case-by-case basis as we move the documentation from the docstrings to the user guide.