Those optional dev dependencies (besides cython) are not part of the build from source doc. We should either add insert an item on the latter and cross-link back to this doc in the last item.

I think it's better to keep upstream remote configuration as a specific items because first time contributors are often confused by the remote configuration so I believe it's important to have a linkable bullet item for this. Then at the end if this item, I would add something like:

"""
You can check that the upstream and origin remote aliases are probably configured with the git remote -v command. It should display something like the following.

origin	https://github.com/mygithubname/scikit-learn.git (fetch)
origin	https://github.com/mygithubname/scikit-learn.git (push)
upstream	https://github.com/scikit-learn/scikit-learn.git (fetch)
upstream	https://github.com/scikit-learn/scikit-learn.git (push)

with those remote repository aliases in place, doing:

  .. prompt:: bash $
    git pull upstream main

will be equivalent to the explicit:

  .. prompt:: bash $
    git pull https://github.com/scikit-learn/scikit-learn.git main

"""

Note that I used the HTTPS URL not to introduce the complexity of setting up ssh. Maybe we should update the advanced installation doc to also use the https:// URL for consistency.

I updated everything to use SSH since most of our git clone are targeting ssh. I also adding the check for git remote -v for checking the remotes.

As for git pull upstream main, in step 7, we already describe a similar workflow:

git checkout main
git fetch upstream
git merge upstream/main

I like the fetch+merge a little better, since it is the same steps for syncing a local branch with upstream/main.

+1 for fetch and merge because it does not depend on the git config for the rebase/merge behavior of the git pull command.

@ogrisel @thomasjpfan

• 1
  It is good to see the fork information in here.

The page is called "Contributing" and for the text "If you plan on submitting a pull-request, you should clone from your fork instead," it's helpful for the user to have the remotes prominently part of the workflow.

I am not mistaken, you only need to install pre-commit that at the first commit will install flake8 mypy and black==21.6b0. It is indeed the step 9. below that is stated optional.

I think that we should remove the **optional** because it would be disregarded easily. I think that most of the time it is a good practice to install pre-commit because it will run black which is the main source of linting issues.

So in step 9. below, I would:

• remove the optional part
• emphasize that they are not required but will ensure that the commit changes will not fail the linting
• mention that you can skip pre-commit using the flag --no-verify when commiting.

I am not mistaken, you only need to install pre-commit that at the first commit will install flake8 mypy and black==21.6b0.

My understanding is that pre-commit installs black in it's own virtual environment. If we want contributors to have black in their development environment, then they would still need install black.

I think we can merge this and follow up with a PR if we want required pre-commit.