✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: f0358af. Link to the linter CI: here}

Thanks a lot, @betatim!

Below, we have the sentence "We are glad to accept any sort of documentation:" (currently line 705) quite prominently. I would think regarding our discussion, that's also not fully true and we should rather hint to that there are of cause conditions?

Good point. "Thoughtful documentation contributions, not copied directly from a LLM..." 😅

Happy to change it, in particular because I am not quite sure what that sentence is trying to say right now. It feels like documentation isn't a thing you can accept - you can accept contributions to the documentation.

Maybe something like "The project contains many kinds of documentation, contributions to any of these are welcome:"? What do you think?

I would skip the comment about LLMs, feels like going into the details too soon and it is already discussed in the "Automated contributions policy" section.

Maybe something like "The project contains many kinds of documentation, contributions to any of these are welcome:"? What do you think?

Hm, I think we want to foreshadow that not any addition to the documentation will be accepted, for expectation management.

Maybe:
"We welcome thoughtful contributions to the documentation and are happy to review additions in the following areas:"
(?)

I added it

@reshamas maybe also has some ideas?

Adding here the transcript to Andy's video for reference:
https://github.com/data-umbrella/data-umbrella-scikit-learn-sprint/blob/master/1_transcript_ACM_contributing_sklearn.md

slide 14:

I've been with the project for a long time and basically any pull requests that I do will have a long discussion and will undergo many iterations before it gets merged, if it gets merged.

slide 15:

So there's also other ways to contribute then finding an issue and working on them. You can also just fix something in the docs that's unclear. You don't necessarily need to open issue for this, so just like improve the documentation if there's something you don't like about it. Or just open issues. Open issues about unclear docs, about features that you find weird, about examples that are not helpful, about bugs you run into.

Particularly slide 19:

That is because scikit-learn is already quite a mature library and so it's moving quite slowly.

Yeah so if you want to add a major features to scikit-learn, that's probably not something you can do in a day. Adding a new model to scikit-learn is usually something that take many months and it's not something you should try to attempt at the beginning. So really start with something simple and then maybe if you got your first first two pull requests and you can work at adding like a smaller feature but don't count on adding a big feature anytime soon. That is because scikit-learn is already quite a mature library and so it's moving quite slowly. And so it's hard to add anything big or make any big new changes. Also there might be a lot of interesting issues that are not appropriately tagged. So if you're interested in particular topic you can just search the topic on the issue tracker or on the pull requests and see if there's something interesting happening there.

@betatim @StefanieSenger
I think this PR is a good start. I have extensive changes I would like to make, but need to map them out (in the same way I did with #31519), but I can do that at a later time.

@reshamas I think taking a "big picture" view of revising thing sis a good idea. Like you said it will require a bit of preparation. Is it ok if we do that outside of this PR and don't wait for it before merging this?

It isn't clear to me what we should do in this PR with the snippets of Andy's talk? To me it feels like a lot of what he said is reflected already in the guide: start small, PRs often go unmerged (no matter who you are), adding a new feature/algorithm is one of the hardest things known to humankind