DOC update documentation instruction after introducing towncrier (scikit-learn#30083)

Co-authored-by: Loïc Estève <loic.esteve@ymail.com>

Author: glemaitre

doc/developers/contributing.rst

@@ -431,13 +431,17 @@ complies with the following rules before marking a PR as "ready for review". The
    non-regression tests should fail for the code base in the ``main`` branch
    and pass for the PR code.
 
-5. Follow the :ref:`coding-guidelines`.
+5. If your PR is likely to affect users, you need to add a changelog entry describing
+   your PR changes, see the `following README <https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md>`
+   for more details.
 
-6. When applicable, use the validation tools and scripts in the :mod:`sklearn.utils`
+6. Follow the :ref:`coding-guidelines`.
+
+7. When applicable, use the validation tools and scripts in the :mod:`sklearn.utils`
    module. A list of utility routines available for developers can be found in the
    :ref:`developers-utils` page.
 
-7. Often pull requests resolve one or more other issues (or pull requests).
+8. Often pull requests resolve one or more other issues (or pull requests).
    If merging your pull request means that some other issues/PRs should
    be closed, you should `use keywords to create link to them
    <https://github.com/blog/1506-closing-issues-via-pull-requests/>`_
@@ -447,7 +451,7 @@ complies with the following rules before marking a PR as "ready for review". The
    related to some other issues/PRs, or it only partially resolves the target
    issue, create a link to them without using the keywords (e.g., ``Towards #1234``).
 
-8. PRs should often substantiate the change, through benchmarks of
+9. PRs should often substantiate the change, through benchmarks of
    performance and efficiency (see :ref:`monitoring_performances`) or through
    examples of usage. Examples also illustrate the features and intricacies of
    the library to users. Have a look at other examples in the `examples/
@@ -456,14 +460,14 @@ complies with the following rules before marking a PR as "ready for review". The
    functionality is useful in practice and, if possible, compare it to other
    methods available in scikit-learn.
 
-9. New features have some maintenance overhead. We expect PR authors
-   to take part in the maintenance for the code they submit, at least
-   initially. New features need to be illustrated with narrative
-   documentation in the user guide, with small code snippets.
-   If relevant, please also add references in the literature, with PDF links
-   when possible.
+10. New features have some maintenance overhead. We expect PR authors
+    to take part in the maintenance for the code they submit, at least
+    initially. New features need to be illustrated with narrative
+    documentation in the user guide, with small code snippets.
+    If relevant, please also add references in the literature, with PDF links
+    when possible.
 
-10. The user guide should also include expected time and space complexity
+11. The user guide should also include expected time and space complexity
     of the algorithm and scalability, e.g. "this algorithm can scale to a
     large number of samples > 100000, but does not scale in dimensionality:
     `n_features` is expected to be lower than 100".

doc/developers/maintainer.rst.template

@@ -29,11 +29,6 @@ We adopted the following release schedule:
   done as a runnable example and check that its HTML rendering looks correct. It should
   be linked from the what's new file for the new version of scikit-learn.
 
-- Ensure that the changelog and commits correspond, and that the changelog is reasonably
-  well curated. In particular, make sure that the changelog entries are labeled and
-  ordered within each section. The order of the labels should be `|MajorFeature|`,
-  `|Feature|`, `|Efficiency|`, `|Enhancement|`, `|Fix|`, and `|API|`.
-
 .. rubric:: Permissions
 
 - The release manager must be a **maintainer** of the
@@ -102,7 +97,7 @@ Reference Steps
       - Do not remove lines but drop commit by replacing `pick` with `drop`.
       - Commits to pick for a bug-fix release are *generally* prefixed with `FIX`, `CI`,
         and `DOC`. They should at least include all the commits of the merged PRs that
-        were milestoned for this release and/or documented as such in the changelog.
+        were milestoned for this release.
       - Commits to `drop` for a bug-fix release are *generally* prefixed with `FEAT`,
         `MAINT`, `ENH`, and `API`. Reasons for not including them is to prevent change
         of behavior (which should only happen in major/minor releases).
@@ -148,9 +143,8 @@ Reference Steps
       variable in `sklearn/__init__.py`. This means while we are in the release
       candidate period, the latest stable is two version behind the `main` branch,
       instead of one. In this PR targeting `main`, you should also include a new what's
-      new file under the `doc/whats_new/` directory so PRs that target the next version
-      can contribute their changelog entries to this file in parallel to the release
-      process.
+      new file under the `doc/whats_new/` directory so that we prepare the
+      changelog for the next release.
     {% endif %}
 
     - In the release branch, change the version number `__version__` in

doc/developers/tips.rst

@@ -234,7 +234,7 @@ PR-MRG: Add to what's new
 
 ::
 
-    Please add an entry to the change log at `doc/whats_new/v*.rst`. Like the other entries there, please reference this pull request with `:pr:` and credit yourself (and other contributors if applicable) with `:user:`.
+    Please add an entry to the future changelog by adding an RST fragment into the module associated with your change located in `doc/whats_new/upcoming_changes`. Refer to the following [README](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md) for full instructions.
 
 PR: Don't change unrelated