Minor grammar fixes and a glossary entry for "open source" (#1809)

nedbat · web-flow · commit 45e3338d5113 · 2026-05-24T10:19:26.000-04:00
diff --git a/core-team/motivations.rst b/core-team/motivations.rst
@@ -115,7 +115,7 @@ participating in the CPython core development process:
    As a core team member, she is primarily interested in helping to ensure Python's
    continued suitability for educational, testing and data analysis use cases,
    as well as in encouraging good architectural practices when assembling Python
-   applications and test harnesses from open source components.
+   applications and test harnesses from open-source components.
 
    Note: prior to August 2023, Alyssa used her birth name (Nick Coghlan). Some records
    (for example, mailing list archives, version control history) will still reference that name.
@@ -175,14 +175,14 @@ participating in the CPython core development process:
    available, working on the infrastructure that supports CPython development,
    specifically the Roundup-based bug tracker and the buildbot system.
 
-   David currently does both proprietary and open source development work,
+   David currently does both proprietary and open-source development work,
    primarily in Python, through the company in which he is a partner, `Murray &
    Walker, Inc <https://www.murrayandwalker.com>`__.  He has done contract work
    focused specifically on CPython development both through the PSF (the
    kickstart of the email Unicode API development) and directly funded by
    interested corporations (additional development work on email funded by
    QNX, and work on CPython ICC support funded by Intel).  He would like to
-   spend more of his (and his company's) time on open source work, and so is
+   spend more of his (and his company's) time on open-source work, and so is
    actively seeking additional such contract opportunities.
 
 .. topic:: Antoine Pitrou (France)
@@ -202,7 +202,7 @@ participating in the CPython core development process:
    concurrent programming.
 
    As a professional, Antoine has been first specializing in network
-   programming, and more lately in open source data science infrastructure.
+   programming, and more lately in open-source data science infrastructure.
    He has made numerous contributions to Numba, Dask and is currently working
    full time on Apache Arrow as a technical leader at QuantStack.
 
@@ -269,7 +269,7 @@ participating in the CPython core development process:
 
    Carol is focused on Python's usage in education and scientific research.
    She is interested in distributed computing, organizational development,
-   operational workflows, and sustainability of open source projects.
+   operational workflows, and sustainability of open-source projects.
 
 
 .. _goals-of-the-motivations-page:
@@ -282,7 +282,7 @@ strongly suggest that the current core development process is bottlenecked on
 core team time. This is most clearly indicated in the first metrics graph,
 which shows both the number of open issues and the number of pull requests awaiting
 review growing steadily over time, despite CPython being one of the most
-active open source projects in the world. This bottleneck then impacts not only
+active open-source projects in the world. This bottleneck then impacts not only
 resolving open issues and accepting submitted pull requests, but also the process of
 identifying, nominating and mentoring new core team members.
 
diff --git a/core-team/responsibilities.rst b/core-team/responsibilities.rst
@@ -123,7 +123,7 @@ to better assess the sustainability of current contributions to CPython core
 development, and also serves as a referral list for organisations seeking
 commercial Python support from the core development community.
 
-And finally, enjoy yourself! Contributing to open source software should be fun
+And finally, enjoy yourself! Contributing to open-source software should be fun
 (overall). If you find yourself no longer enjoying the work then either take a
 break or figure out what you need to do to make it enjoyable again.
 
diff --git a/developer-workflow/communication-channels.rst b/developer-workflow/communication-channels.rst
@@ -270,7 +270,7 @@ that way. You can find their blogs (and various other developers who use Python)
 at `Planet Python <https://planetpython.org/>`__.
 
 
-Setting expectations for open source participation
+Setting expectations for open-source participation
 ==================================================
 
 Burn-out is common in open source due to a misunderstanding of what users, contributors,
diff --git a/developer-workflow/extension-modules.rst b/developer-workflow/extension-modules.rst
@@ -547,7 +547,7 @@ Now that the configuration is in place, it remains to compile the project:
 
 .. tip::
 
-   Use ``make -jN`` to speed-up compilation by utilizing as many CPU cores
+   Use ``make -jN`` to speed up compilation by utilizing as many CPU cores
    as possible, where *N* is as many CPU cores you want to spare (and have
    memory for). Be careful using ``make -j`` with no argument, as this puts
    no limit on the number of jobs, and compilation can sometimes use up a
diff --git a/developer-workflow/stdlib.rst b/developer-workflow/stdlib.rst
@@ -126,7 +126,7 @@ If the module you want to propose adding to the stdlib meets the requirements,
 you may propose its inclusion
 by following the :abbr:`PEP (Python Enhancement Proposal)` process.
 See :pep:`1` for details,
-and the :pep:`PEP index <0>` for previously-accepted PEPs
+and the :pep:`PEP index <0>` for previously accepted PEPs
 that have proposed a module for inclusion.
 
 If the PEP is accepted, then the module will be added to the stdlib
diff --git a/development-tools/warnings.rst b/development-tools/warnings.rst
@@ -29,7 +29,7 @@ What to do if a warning check fails GitHub CI
 ---------------------------------------------
 
 The :cpy-file:`Tools/build/check_warnings.py` tool will fail if the compiler generates
-more or less warnings than expected for a given source file as defined in the
+more or fewer warnings than expected for a given source file as defined in the
 platform-specific warning ignore file. The warning ignore file is either
 :cpy-file:`Tools/build/.warningignore_ubuntu` or
 :cpy-file:`Tools/build/.warningignore_macos` depending on the platform.
@@ -44,7 +44,7 @@ If a warning check fails with:
     warning ignore file. If the file exists in the warning ignore file
     increment the count by the number of newly introduced warnings.
 
-* Unexpected improvements (less warnings)
+* Unexpected improvements (fewer warnings)
 
   * Document in the PR that the change reduces the number of compiler
     warnings. Decrement the count in the platform-specific warning
diff --git a/documentation/markup.rst b/documentation/markup.rst
@@ -225,7 +225,7 @@ Explicit markup
 ---------------
 
 "Explicit markup" is used in reST for most constructs that need special
-handling, such as footnotes, specially-highlighted paragraphs, comments, and
+handling, such as footnotes, specially highlighted paragraphs, comments, and
 generic directives.
 
 An explicit markup block begins with a line starting with ``..`` followed by
diff --git a/documentation/style-guide.rst b/documentation/style-guide.rst
@@ -84,6 +84,11 @@ free-threaded
    lock (GIL) optional (per :pep:`703`). Avoid using "No-GIL" to avoid
    double negatives (for example, "non-no-GIL").
 
+open source
+   Follow the usual English rules for compound words. When used as an
+   adjective, hyphenate: "open-source software". When used as a noun, don't use
+   a hypen: "open source is a collaboration model.."
+
 POSIX
    The name assigned to a particular group of standards. This is always
    uppercase.
@@ -92,7 +97,7 @@ Python
    The name of our favorite programming language is always capitalized.
 
 reST
-   For "reStructuredText," an easy to read, plaintext markup syntax
+   For "reStructuredText," an easy to read, plain-text markup syntax
    used to produce Python documentation.  When spelled out, it is
    always one word and both forms start with a lowercase 'r'.
 
diff --git a/getting-started/setup-building.rst b/getting-started/setup-building.rst
@@ -83,7 +83,7 @@ You will only need to execute these steps once per machine:
 
    (You can use both SSH-based or HTTPS-based URLs.)
 
-.. Step 6 and 7 are are duplicated in bootcamp as well.
+.. Step 6 and 7 are duplicated in bootcamp as well.
    Please update these steps in both places.
 
 6. Add an ``upstream`` remote, then configure ``git``
