[PATCH] docs: process/2.Process.rst: fixes five general grammatical errors

[PATCH] docs: process/2.Process.rst: fixes five general grammatical errors

[Hunter Chasens]

Signed-off-by: Hunter Chasens <hunter.chasens18@ncf.edu>
---
 Documentation/process/2.Process.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index e05fb1b8f..31e370073 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -68,7 +68,7 @@ As fixes make their way into the mainline, the patch rate will slow over
 time.  Linus releases new -rc kernels about once a week; a normal series
 will get up to somewhere between -rc6 and -rc9 before the kernel is
 considered to be sufficiently stable and the final release is made.
-At that point the whole process starts over again.
+At that point, the whole process starts over again.
 
 As an example, here is how the 5.4 development cycle went (all dates in
 2019):
@@ -166,7 +166,7 @@ The stages that a patch goes through are, generally:
  - Design.  This is where the real requirements for the patch - and the way
    those requirements will be met - are laid out.  Design work is often
    done without involving the community, but it is better to do this work
-   in the open if at all possible; it can save a lot of time redesigning
+   in the open, if at all possible; it can save a lot of time redesigning
    things later.
 
  - Early review.  Patches are posted to the relevant mailing list, and
@@ -174,12 +174,12 @@ The stages that a patch goes through are, generally:
    process should turn up any major problems with a patch if all goes
    well.
 
- - Wider review.  When the patch is getting close to ready for mainline
+ - Wider review.  When the patch is getting close to being ready for mainline
    inclusion, it should be accepted by a relevant subsystem maintainer -
    though this acceptance is not a guarantee that the patch will make it
    all the way to the mainline.  The patch will show up in the maintainer's
    subsystem tree and into the -next trees (described below).  When the
-   process works, this step leads to more extensive review of the patch and
+   process works, this step leads to a more extensive review of the patch and
    the discovery of any problems resulting from the integration of this
    patch with work being done by others.
 
@@ -408,7 +408,7 @@ There are lists hosted elsewhere, though; a number of them are at
 redhat.com/mailman/listinfo.
 
 The core mailing list for kernel development is, of course, linux-kernel.
-This list is an intimidating place to be; volume can reach 500 messages per
+This list is an intimidating place to be; the volume can reach 500 messages per
 day, the amount of noise is high, the conversation can be severely
 technical, and participants are not always concerned with showing a high
 degree of politeness.  But there is no other place where the kernel
-- 
2.25.1

Re: [PATCH] docs: process/2.Process.rst: fixes five general grammatical errors

[Matthew Wilcox]

On Sat, Jan 15, 2022 at 05:30:40PM -0500, Hunter Chasens wrote:

You actually need a changelog here, not just a subject.

> -At that point the whole process starts over again.
> +At that point, the whole process starts over again.

This change is good.

>     those requirements will be met - are laid out.  Design work is often
>     done without involving the community, but it is better to do this work
> -   in the open if at all possible; it can save a lot of time redesigning
> +   in the open, if at all possible; it can save a lot of time redesigning
>     things later.

This is arguable.  I would prefer it without the comma.

> - - Wider review.  When the patch is getting close to ready for mainline
> + - Wider review.  When the patch is getting close to being ready for mainline
>     inclusion, it should be accepted by a relevant subsystem maintainer -

Again, I don't really see the point of this change.

>     though this acceptance is not a guarantee that the patch will make it
>     all the way to the mainline.  The patch will show up in the maintainer's
>     subsystem tree and into the -next trees (described below).  When the
> -   process works, this step leads to more extensive review of the patch and
> +   process works, this step leads to a more extensive review of the patch and
>     the discovery of any problems resulting from the integration of this
>     patch with work being done by others.

You're taking "review" as a noun, but if you take it as a verb, the
sentence is gramatically correct.

> @@ -408,7 +408,7 @@ There are lists hosted elsewhere, though; a number of them are at
>  redhat.com/mailman/listinfo.
>  
>  The core mailing list for kernel development is, of course, linux-kernel.
> -This list is an intimidating place to be; volume can reach 500 messages per
> +This list is an intimidating place to be; the volume can reach 500 messages per
>  day, the amount of noise is high, the conversation can be severely

This change is fine.

Overall, I wouldn't encourage you to send more nitpicking patches
like this.  The cost of review is more than the value of correctness.
By all means correct documentation that's misleading or fix obvious
spelling mistakes, but grammatical errors aren't worth it.