[pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

Author: pre-commit-ci[bot]

docs/monthly-meeting/2024-01.md

@@ -37,7 +37,7 @@ Please take a second to read through it!
 
 > This is a place to make announcements (without a need for discussion). This is also a great place to give shout-outs to contributors! We'll read through these at the beginning of the meeting.
 
-* The Steering Council has [accepted](https://discuss.python.org/t/pep-732-the-python-documentation-editorial-board/36710/9?u=hugovk) [PEP 732](https://peps.python.org/pep-0732/) ("The Python Documentation Editorial Board") 🎉 
+* The Steering Council has [accepted](https://discuss.python.org/t/pep-732-the-python-documentation-editorial-board/36710/9?u=hugovk) [PEP 732](https://peps.python.org/pep-0732/) ("The Python Documentation Editorial Board") 🎉
 
    - [willingc] First meeting will be January 8, 2024.
    - [Carol] Looing at docs and website from a new user's perspective
@@ -53,7 +53,7 @@ Please take a second to read through it!
 
   The `tkinter`, `pty`/`termios`, `sqlite3` (maybe more?) use `master/slave` terminology in API and docs. What's the best way to come up with, and switch to, better terms?
 
-  Is there an expert* I should talk to? 
+  Is there an expert* I should talk to?
 
   - [willingc] Thursday Bram has authored a Responsible Communications book which may have helpful guidelines. Other communities have used `leader/follower`. [Linux PR on the subject](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb)
   - [Hugo] Some suggestions: https://www.ietf.org/archive/id/draft-knodel-terminology-14.html#name-master-slave (willingc: I like the suggestions in this document for different usages.)
@@ -102,9 +102,9 @@ Please take a second to read through it!
 - [Ryan] standard library documentation reference and adding types to it in a structured way.  For example, `collections.Counter.most_common` could be written
 
       most_common(n: int) -> list[tuple[Any, int]]
-  
+
   [Petr] ... or `list[tuple[KeyType, int]]`?
-  
+
   - this has been discussed. There was opposition to adding the types to the stdlib code itself.
   - [Jim] I sometimes wish for more normative, less chatty module documentation. e.g. [*heapq* module](https://docs.python.org/3/library/heapq.html). e.g. old issue 29428 [*Doctest documentation unclear about multi-line fixtures*](https://bugs.python.org/issue29428).
  bad example commit messages