@@ -282,32 +282,83 @@ to the standard library). The file name itself should be in the format
282282As a result, a file name can look something like
283283``Misc/NEWS.d/next/Library/2017-05-27-16-46-23.gh-issue-12345.Yl4gI2.rst ``.
284284
285+ .. _news-entry-writing :
286+
285287How to write a NEWS entry
286288-------------------------
287289
288290All ``NEWS `` entries end up being part of the changelog.
289291The changelog contains *a lot * of entries,
290292and its intended audience is mainly users, not core devs and contributors.
291- Take this into consideration when wording your ``NEWS `` entry.
292- Describe the user-visible effects of your change succinctly and accurately;
293- avoid long technical elaborations, digressions, and do not expect or require
294- the reader to have read the actual diff for the change.
295-
296- The contents of a ``NEWS `` file should be valid reStructuredText. An 80 character
297- column width should be used. There is no indentation or leading marker in the
298- file (for example, ``- ``). There is also no need to start the entry with the issue
299- number since it is part of the file name. You can use
300- :ref: `inline markups <rest-inline-markup >` too. Here is an example of a ``NEWS ``
301- entry:
293+ Readers scan it to find out whether an upgrade affects them,
294+ or to track down the change behind a new behavior.
295+ Most of them will not read the issue or the diff, so the entry must stand alone.
296+
297+ What to say
298+ ^^^^^^^^^^^
299+
300+ A good ``NEWS `` entry is one or two sentences long.
301+
302+ * Start with a verb in the imperative mood that says what kind of change
303+ it is: *Fix *, *Add *, *Remove *, *Deprecate *, *Allow *, *Raise *.
304+ * Name what changed, using :ref: `inline markup <rest-inline-markup >`
305+ such as ``:func: ``, ``:class: `` or ``:mod: ``,
306+ so readers can jump to the documentation.
307+ * Say what a user will notice, and under what conditions.
308+ * Stop.
309+
310+ Leave out:
311+
312+ * Implementation details and the root cause of a bug.
313+ * What happened before the change, if the fix already implies it.
314+ * How the problem was found, or who reported it.
315+ * Tests that were added or changed.
316+ * Benchmark figures, unless the change is a performance improvement.
317+ * Filler such as "improves robustness" or "makes the code cleaner".
318+ * Phrases that refer to the pull request itself, such as "this PR"
319+ or "this change".
320+
321+ Attribution is optional and does not count toward the length.
322+ If you want it, name the people who wrote the patch in a final sentence
323+ of the form ``Patch by Jane Doe. ``
324+
325+ Examples
326+ ^^^^^^^^
327+
328+ Preferred:
302329
303330.. code-block :: rst
331+ :class: good
304332
305- Fix warning message when :func:`os.chdir` fails inside
306- :func:`test.support.temp_cwd`. Contributed by Chris Jerdonek.
333+ Fix :class:`logging.handlers.TimedRotatingFileHandler` permanently stopping
334+ rollover after a rollover failed or its backup file already existed, for
335+ example at a DST change.
307336
308- The inline Sphinx roles like :rst:role: `:func: <py:func> ` can be used help readers
309- find more information. You can build HTML and verify that the
310- link target is appropriate by using :ref: `make html <building-using-make >`.
337+ Not preferred, the same change with too much detail:
338+
339+ .. code-block :: rst
340+ :class: bad
341+
342+ Fix :class:`logging.handlers.TimedRotatingFileHandler` so that it keeps
343+ rolling over after a rollover fails or finds that the backup file already
344+ exists, for example after a DST change. Previously the handler stopped
345+ rolling over permanently, so the base log file grew without bound and old
346+ backups were no longer removed.
347+
348+ Nothing in the second version is wrong, but the second sentence only
349+ restates the bug that the first sentence already says is fixed.
350+ A reader who wants that level of detail can follow the issue link
351+ in the changelog.
352+
353+ Format
354+ ^^^^^^
355+
356+ The contents of a ``NEWS `` file should be valid reStructuredText,
357+ wrapped at 80 characters. There is no indentation or leading marker in the
358+ file (for example, ``- ``), and no need to start with the issue number,
359+ since it is already part of the file name.
360+ You can build HTML and verify that the link targets are appropriate
361+ by using :ref: `make html <building-using-make >`.
311362
312363
313364Copyrights
0 commit comments