Skip to content

Commit 30db853

Browse files
committed
DOC: Improve What's new entry description
1 parent b8ee229 commit 30db853

File tree

4 files changed

+25
-13
lines changed

4 files changed

+25
-13
lines changed

doc/api/next_api_changes/README.rst

+2-1
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,7 @@ A typical entry could look like this::
3939

4040
Please avoid using references in section titles, as it causes links to be
4141
confusing in the table of contents. Instead, ensure that a reference is
42-
included in the descriptive text.
42+
included in the descriptive text. Use inline literals (double backticks)
43+
to denote code objects in the title.
4344

4445
.. api-change-guide-end

doc/devel/api_changes.rst

+6-3
Original file line numberDiff line numberDiff line change
@@ -13,8 +13,8 @@ the API and any changes, either semantic or aesthetic, are backwards-incompatibl
1313
API changes.
1414

1515

16-
Add new API and features
17-
------------------------
16+
Add new API
17+
-----------
1818

1919
Every new function, parameter and attribute that is not explicitly marked as
2020
private (i.e., starts with an underscore) becomes part of Matplotlib's public
@@ -210,7 +210,8 @@ Announce new and deprecated API
210210

211211
When adding or changing the API in a backward in-compatible way, please add the
212212
appropriate :ref:`versioning directive <versioning-directives>` and document it
213-
for the release notes and add the entry to the appropriate folder:
213+
in the :ref:`release notes <release-notes>` by adding an entry to the appropriate
214+
folder:
214215

215216
+-------------------+-----------------------------+----------------------------------------------+
216217
| | versioning directive | announcement folder |
@@ -278,6 +279,8 @@ For classes and functions, the directive should be placed before the
278279
end of the parameter description. The micro release version is omitted and
279280
the directive should not be added to entire modules.
280281

282+
.. _release-notes:
283+
281284
Release notes
282285
^^^^^^^^^^^^^
283286

doc/devel/pr_guide.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ guidelines before submitting a pull request:
4141
* For high-level plotting functions, consider adding a small example to the
4242
:ref:`examples gallery <gallery>`.
4343

44-
* If you add a major new feature or change the API in a backward-incompatible
44+
* If you add a new feature or change the API in a backward-incompatible
4545
way, please document it as described in :ref:`api_changes`.
4646

4747
* Code should follow our conventions as documented in our :ref:`coding_guidelines`.

doc/users/next_whats_new/README.rst

+16-8
Original file line numberDiff line numberDiff line change
@@ -9,11 +9,14 @@
99
1010
Instructions for writing "What's new" entries
1111
=============================================
12-
1312
.. whats-new-guide-start
1413
15-
Please place new portions of :file:`whats_new.rst` in the
16-
:file:`doc/users/next_whats_new/` directory.
14+
Each new feature (e.g. function, parameter, config value, behavior, ...) must
15+
be described through a "What's new" entry.
16+
17+
Each entry is written into a separate file in the
18+
:file:`doc/users/next_whats_new/` directory. They are sorted and merged into
19+
:file:`whats_new.rst` during the release process.
1720

1821
When adding an entry please look at the currently existing files to
1922
see if you can extend any of them. If you create a file, name it
@@ -26,14 +29,19 @@ Include contents of the form::
2629
Section title for feature
2730
-------------------------
2831

29-
A bunch of text about how awesome the new feature is and examples of how
30-
to use it.
32+
A description of the feature from the user perspective. This should include
33+
what the feature allows users to do and how the feature is used. Technical
34+
details should be left out when they do not impact usage, for example
35+
implementation details.
3136

32-
A sub-section
33-
~~~~~~~~~~~~~
37+
The description may include a a short instructive example, if it helps to
38+
understand the feature.
3439

3540
Please avoid using references in section titles, as it causes links to be
3641
confusing in the table of contents. Instead, ensure that a reference is
37-
included in the descriptive text.
42+
included in the descriptive text. Use inline literals (double backticks)
43+
to denote code objects in the title.
44+
45+
3846

3947
.. whats-new-guide-end

0 commit comments

Comments
 (0)