Skip to content

Navigation Menu

Sign in

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Add links to examples from the docstrings and user guide #30621

New issue
Copy link
New issue
Copy link
Open
Open
Add links to examples from the docstrings and user guide#30621
Copy link
Labels
DocumentationMeta-issueGeneral issue associated to an identified list of tasksGeneral issue associated to an identified list of tasksSprintgood first issueEasy with clear instructions to resolveEasy with clear instructions to resolve
@StefanieSenger

Description

@StefanieSenger
StefanieSenger
opened on Jan 10, 2025
Issue body actions

TLDR: Meta-issue for new contributors to add links to the examples in helpful places of the rest of the docs.

Description

This meta-issue is a good place to start with your first contributions to scikit-learn.

This issue builds on top of #26927 and is introduced for easier maintainability. The goal is exactly the same as in the old issue.

Here, we improve the documentation by making the Examples more discoverable by adding links to examples in relevant sections of the documentation in the API documentation and in the User Guide:

  • the API documentation is made from the docstrings of public classes and functions which can be found in the sklearn folder of the project
  • the User Guide can be found in the doc/modules folder of the project

Together with the examples (which are in the examples folder of the project), these files get rendered into html when the documentation is build and then are displayed on the scikit-learn website.

Important: We estimate that only 70% of the examples in this list will ultimately be referenced. This means part of the task is deciding which examples deserve being referenced and we are aware that this is not a trivial decision, especially for new contributors. We encourage you to share your reasoning, and a team member will make the final call. We hope this isn’t too frustrating, but please know that evaluating an example is not just an exercise for new contributors; it’s a meaningful and valuable contribution to the project, even (and especially) if the example you worked on doesn’t end up being linked.

Workflow

We recommend this workflow for you:

  1. have pre-commit installed in your environment as in point 10 of How to contribute in the development guide (this will re-format your contribution to the standards used in scikit-learn and will spare you a lot of confusion when you are a beginner)

  2. pick an example to work on

    • Make sure your example of interest had not recently been claimed by someone else by looking through the discussion of this issue (you will have to load hidden items in this discussion). Hint: If somebody has claimed an example several weeks ago and then never started it, you can take it. You can also take over tasks marked as stalled.
    • search the repo for other links to your example and check if the example is already linked in relevant parts of the docs
      • how to search the repo: a) find the file name of your example in the examples folder (it starts with plot_...); b) use full text search of your IDE to look for where that name appears
      • you can totally ignore the "Gallery examples" on the website, as it is auto-generated; do only look for real links in the repo
    • comment on the issue to claim an example (you don't need to wait for a team member's approval before starting to work)

  3. find suitable spots in either the API documentation or the User Guide (or both) where users would be happy to find your example linked

    • read through your example and understand where it is making its most useful statements
    • how to find a good spot (careful: we are extremely picky here)
      • if the example demonstrates a certain real world use case: find where in the User Guide the same use case is treated or could be treated
      • if the example shows how to use a certain param: the param description in the API documentation might be a good spot to put the link
      • if the example compares different techniques: this highly calls for mentioning it in the more theoretical parts of the User Guide
      • not all the examples listed here need to be referenced: a link to an example on simply how to use some estimator, doesn't add enough value
        • if you find an example that doesn't add enough value to be linked: please leave a comment here; this kind of contribution is highly appreciated
    • not a good spot: the See Also section, which is (theoretically) reserved for links to other API functionalities, not examples

  4. add links

    • An example with the path examples/developing_estimators/sklearn_is_fitted.py whould be referenced like this:
      :ref:`sphx_glr_auto_examples_developing_estimators_sklearn_is_fitted.py`
    • see this example PR, that shows how to add a link to the User Guide: DOC add link to sklearn_is_fitted example in check_is_fitted #26926
    • we aim not to use the .. rubric:: Examples section to put the example if possible, but to integrate it into the text; be aware that if you add a link like this :ref:`title <link>`, you can change its title so that the example's title gets substituted by your picked title and the link can be fitted more nicely to the sentences
    • please avoid adding your link to a list of other examples, since we strive to add the links in the most relevant places
    • please avoid adding a new .. rubric:: Examples section

  5. test build the documentation before opening your PR

  6. open PR

    • use a PR title like DOC add links to <name of example> (starting with DOC)
    • do not refer to this issue on the title of the PR, instead:
    • do refer to this issue using in the Reference Issues/PRs section of your PR, do refer to this issue using "Towards #30621" (do not use "Closes #..." or "Fixes #...")

  7. check the CI

    • After the CI tests have finished (~90 minutes) you can find one that says "Check the rendered docs here!". In there, you can look into how the CI has built the documentation for the changed files to check if everything looks alright. You will see something like auto_examples/path_to_example, [dev], [stable], where the first link is your branche's version, the second is the main dev branch and the third link is the last released scikit-learn version that is used for the stable documentation on the website.
    • if the CI shows any failure, you should to take action by investigating and proposing solutions; as a rule of thump, you can find the most useful information from the CIs, if you click the upper links first; in any case you need to click through several layers until you see actual test results with more information (and until it looks similar to running pytest, ruff or doctest locally)
    • if the CI shows linting issues, check if you have installed and activated pre-commit properly, and fix the issue by the action the CI proposes (for instance adding or deleting an empty line)
    • if you are lost and don't know what to do with a CI failure, look through other PRs from this issue; most things have already happened to others
    • sometimes, http request errors such as 404 or 405 show up in the CI, in which case you should push an empty commit (git commit --allow-empty -m "empty commit to re-trigger CI")

  8. wait for reviews and be ready to adjust your contribution later on

Expectation management for new contributors

How long will your first PR take you up until the point you open a PR?

  • 8-16 hours if you have never contributed to any project and have only basic or no understanding of the workflow yet
  • 2-8 hours if you know the workflow and are just new to scikit-learn (more to the shorter end if you know about linting and sphinx and are able to address CI outputs)
  • 1-2 hours for your 2nd, 3rd, ... PR on the same issue for everyone

How long will it take us to merge your PR?

  • we strive for a scikit-learn member to look at your PR within a few days and suggest changes depending on technical quality of the PR and an assessment of added value to the user
  • we strive for a maintainer to evaluate your PR within a few weeks; they might also suggest changes before approving and merging
  • the whole process on average takes several weeks and can take up months, depending of availability of maintainers and on how many review cycles are necessary

ToDo

Here's a list of all the remaining examples:

What comes next?

Metadata

Metadata

Assignees

No one assigned

    Labels

    DocumentationMeta-issueGeneral issue associated to an identified list of tasksGeneral issue associated to an identified list of tasksSprintgood first issueEasy with clear instructions to resolveEasy with clear instructions to resolve

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions
      Morty Proxy This is a proxified and sanitized view of the page, visit original site.