Skip to content

DOC update documentation instruction after introducing towncrier #30083

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Oct 29, 2024
Merged

DOC update documentation instruction after introducing towncrier #30083

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
584b68a
DOC update documentation instruction after introducing towncrier
glemaitre Oct 16, 2024
6d10e36
iter
glemaitre Oct 17, 2024
211a4ed
Update doc/whats_new/upcoming_changes/README.md
glemaitre Oct 17, 2024
172f67f
Merge remote-tracking branch 'origin/main' into update_towncrier_inst…
glemaitre Oct 17, 2024
70f0f8f
add information in the contributing guideline
glemaitre Oct 17, 2024
ac59e22
update some info in the maintainer info
glemaitre Oct 17, 2024
54da064
Merge branch 'main' into update_towncrier_instruction
glemaitre Oct 29, 2024
289eb8e
Update doc/developers/maintainer.rst.template
glemaitre Oct 29, 2024
c8c61e8
Update doc/developers/contributing.rst
glemaitre Oct 29, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 15 additions & 11 deletions doc/developers/contributing.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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/>`_
Expand All @@ -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/
Expand All @@ -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".
Expand Down
12 changes: 3 additions & 9 deletions doc/developers/maintainer.rst.template
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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).
Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion doc/developers/tips.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down