This patch series performs a thorough pass across several files 
in the Linux kernel process documentation directory. The primary focus
is to improve readability and maintain a professional tone throughout 
the guides for a global developer audience.

Core changes include:
- Expanding conversational contractions (e.g., "don't" to "do not").
- Rectifying minor punctuation oversights and grammatical typos.
- Standardizing terminology formatting to elevate professional voice.

Extra notes:
- I originally intended to send a 12-patch series to cover the whole
  directory, but decided to scale it back to these 5 high-quality
  patches to ensure thorough accuracy and a manageable review cycle.
  
  Also I want to know the current progress of the patch titled 
  "Capitalize Git, Quilt, and Mercurial consistently".

  And I would like to thank everyone for welcoming me to the community
  and I hope everyone can forgive me for my mistakes in the past, 
  present, and in the future.

v2:
  - Resending the complete 5-patch series together as a single cohesive 
    thread. (Apologies, the v1 submission suffered a terminal wildcard 
    argument error that accidentally truncated the transmission 
    after 1/5).

Nguyen Duc Thinh (5):
  Documentation: process: Clean up grammar, tone, and contractions in
    core files
  Documentation: process: Clean up grammar and tone in next guide files
  Documentation: process: Refine language, tone, and grammar in
    subsequent files
  Documentation: process: Refine language, tone, and grammar in
    subsequent files
  Documentation: process: Clean up grammar and tone across multiple
    files

 Documentation/process/1.Intro.rst             | 18 ++---
 Documentation/process/2.Process.rst           | 22 +++---
 Documentation/process/3.Early-stage.rst       | 14 ++--
 Documentation/process/4.Coding.rst            | 48 ++++++-------
 Documentation/process/5.Posting.rst           | 34 +++++-----
 Documentation/process/6.Followthrough.rst     | 16 ++---
 Documentation/process/7.AdvancedTopics.rst    | 32 ++++-----
 Documentation/process/8.Conclusion.rst        |  4 +-
 Documentation/process/applying-patches.rst    | 20 +++---
 Documentation/process/backporting.rst         | 68 +++++++++----------
 Documentation/process/botching-up-ioctls.rst  | 54 +++++++--------
 Documentation/process/changes.rst             | 20 +++---
 .../code-of-conduct-interpretation.rst        | 14 ++--
 Documentation/process/code-of-conduct.rst     |  2 +-
 Documentation/process/coding-assistants.rst   | 12 ++--
 Documentation/process/conclave.rst            |  6 +-
 .../process/contribution-maturity-model.rst   |  4 +-
 Documentation/process/cve.rst                 |  8 +--
 Documentation/process/deprecated.rst          | 14 ++--
 Documentation/process/development-process.rst |  6 +-
 Documentation/process/email-clients.rst       | 32 ++++-----
 21 files changed, 224 insertions(+), 224 deletions(-)

-- 
2.50.1 (Apple Git-155)

Thanks for Cc'ing me.

On Wed, Sep 02, 2026 at 03:43:58PM +0700, Nguyen Duc Thinh wrote:
> This patch series performs a thorough pass across several files 
> in the Linux kernel process documentation directory. The primary focus
> is to improve readability and maintain a professional tone throughout 
> the guides for a global developer audience.
> 
> Core changes include:
> - Expanding conversational contractions (e.g., "don't" to "do not").

Is this necessary? I'm not sure.

> - Rectifying minor punctuation oversights and grammatical typos.
> - Standardizing terminology formatting to elevate professional voice.
> 
> Extra notes:
> - I originally intended to send a 12-patch series to cover the whole
>   directory, but decided to scale it back to these 5 high-quality
>   patches to ensure thorough accuracy and a manageable review cycle.
>   
>   Also I want to know the current progress of the patch titled 
>   "Capitalize Git, Quilt, and Mercurial consistently".

It has been applied:

https://git.kernel.org/pub/scm/linux/kernel/git/docs/linux.git/commit/?id=4a0be1a25d98672391e8ad2a0802f08609397274

> v2:
>   - Resending the complete 5-patch series together as a single cohesive 
>     thread. (Apologies, the v1 submission suffered a terminal wildcard 
>     argument error that accidentally truncated the transmission 
>     after 1/5).

A better practice is to name it [PATCH v1 RESEND], I guess?

> Nguyen Duc Thinh (5):
>   Documentation: process: Clean up grammar, tone, and contractions in
>     core files
>   Documentation: process: Clean up grammar and tone in next guide files
>   Documentation: process: Refine language, tone, and grammar in
>     subsequent files
>   Documentation: process: Refine language, tone, and grammar in
>     subsequent files
>   Documentation: process: Clean up grammar and tone across multiple
>     files

Output of 'b4 shazam':

...
Applying: Documentation: process: Clean up grammar, tone, and contractions in core files
Applying: Documentation: process: Clean up grammar and tone in next guide files
Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
Applying: Documentation: process: Clean up grammar and tone across multiple files
/home/user/Projects/linux/.git/rebase-apply/patch:72: trailing whitespace.
  License (about which more will be said below).  The author is not a
warning: 1 line adds whitespace errors.
/home/user/Projects/linux/.git/rebase-apply/patch:244: trailing whitespace.
Which is nice, since there is no more insanity in the form of fake-generic
warning: 1 line adds whitespace errors.
/home/user/Projects/linux/.git/rebase-apply/patch:261: trailing whitespace.
   rare cases, an AI assistant capable of finding a bug is capable of fixing it.
/home/user/Projects/linux/.git/rebase-apply/patch:262: trailing whitespace.
   Fixes written within the same session used to identify the bug will
/home/user/Projects/linux/.git/rebase-apply/patch:263: trailing whitespace.
   generally lead to better and more accurate fixes as the LLM's reasoning
/home/user/Projects/linux/.git/rebase-apply/patch:282: trailing whitespace.
- Within two weeks, a representative of this group will communicate the
warning: 4 lines add whitespace errors.

Should we handle with whitespace?

Thanks.

On 9/3/26 5:29 AM, Weijie Yuan wrote:
> Thanks for Cc'ing me.
> 
> On Wed, Sep 02, 2026 at 03:43:58PM +0700, Nguyen Duc Thinh wrote:
>> This patch series performs a thorough pass across several files 
>> in the Linux kernel process documentation directory. The primary focus
>> is to improve readability and maintain a professional tone throughout 
>> the guides for a global developer audience.
>>
>> Core changes include:
>> - Expanding conversational contractions (e.g., "don't" to "do not").
> 
> Is this necessary? I'm not sure.
> 
>> - Rectifying minor punctuation oversights and grammatical typos.
>> - Standardizing terminology formatting to elevate professional voice.
>>
>> Extra notes:
>> - I originally intended to send a 12-patch series to cover the whole
>>   directory, but decided to scale it back to these 5 high-quality
>>   patches to ensure thorough accuracy and a manageable review cycle.
>>   
>>   Also I want to know the current progress of the patch titled 
>>   "Capitalize Git, Quilt, and Mercurial consistently".
> 
> It has been applied:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/docs/linux.git/commit/?id=4a0be1a25d98672391e8ad2a0802f08609397274
> 
>> v2:
>>   - Resending the complete 5-patch series together as a single cohesive 
>>     thread. (Apologies, the v1 submission suffered a terminal wildcard 
>>     argument error that accidentally truncated the transmission 
>>     after 1/5).
> 
> A better practice is to name it [PATCH v1 RESEND], I guess?
> 
>> Nguyen Duc Thinh (5):
>>   Documentation: process: Clean up grammar, tone, and contractions in
>>     core files
>>   Documentation: process: Clean up grammar and tone in next guide files
>>   Documentation: process: Refine language, tone, and grammar in
>>     subsequent files
>>   Documentation: process: Refine language, tone, and grammar in
>>     subsequent files
>>   Documentation: process: Clean up grammar and tone across multiple
>>     files
> 
> Output of 'b4 shazam':
> 
> ...
> Applying: Documentation: process: Clean up grammar, tone, and contractions in core files
> Applying: Documentation: process: Clean up grammar and tone in next guide files
> Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> Applying: Documentation: process: Clean up grammar and tone across multiple files
> /home/user/Projects/linux/.git/rebase-apply/patch:72: trailing whitespace.
>   License (about which more will be said below).  The author is not a
> warning: 1 line adds whitespace errors.
> /home/user/Projects/linux/.git/rebase-apply/patch:244: trailing whitespace.
> Which is nice, since there is no more insanity in the form of fake-generic
> warning: 1 line adds whitespace errors.
> /home/user/Projects/linux/.git/rebase-apply/patch:261: trailing whitespace.
>    rare cases, an AI assistant capable of finding a bug is capable of fixing it.
> /home/user/Projects/linux/.git/rebase-apply/patch:262: trailing whitespace.
>    Fixes written within the same session used to identify the bug will
> /home/user/Projects/linux/.git/rebase-apply/patch:263: trailing whitespace.
>    generally lead to better and more accurate fixes as the LLM's reasoning
> /home/user/Projects/linux/.git/rebase-apply/patch:282: trailing whitespace.
> - Within two weeks, a representative of this group will communicate the
> warning: 4 lines add whitespace errors.
> 
> Should we handle with whitespace?

No, the trailing whitespace should be fixed (i.e., deleted)
and then resend the patches.

-- 
~Randy

On Thu, Sep 03, 2026 at 09:33:46AM -0700, Randy Dunlap wrote:
> >> Nguyen Duc Thinh (5):
> >>   Documentation: process: Clean up grammar, tone, and contractions in
> >>     core files
> >>   Documentation: process: Clean up grammar and tone in next guide files
> >>   Documentation: process: Refine language, tone, and grammar in
> >>     subsequent files
> >>   Documentation: process: Refine language, tone, and grammar in
> >>     subsequent files
> >>   Documentation: process: Clean up grammar and tone across multiple
> >>     files
> > 
> > Output of 'b4 shazam':
> > 
> > ...
> > Applying: Documentation: process: Clean up grammar, tone, and contractions in core files
> > Applying: Documentation: process: Clean up grammar and tone in next guide files
> > Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> > Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> > Applying: Documentation: process: Clean up grammar and tone across multiple files
> > /home/user/Projects/linux/.git/rebase-apply/patch:72: trailing whitespace.
> >   License (about which more will be said below).  The author is not a
> > warning: 1 line adds whitespace errors.
> > /home/user/Projects/linux/.git/rebase-apply/patch:244: trailing whitespace.
> > Which is nice, since there is no more insanity in the form of fake-generic
> > warning: 1 line adds whitespace errors.
> > /home/user/Projects/linux/.git/rebase-apply/patch:261: trailing whitespace.
> >    rare cases, an AI assistant capable of finding a bug is capable of fixing it.
> > /home/user/Projects/linux/.git/rebase-apply/patch:262: trailing whitespace.
> >    Fixes written within the same session used to identify the bug will
> > /home/user/Projects/linux/.git/rebase-apply/patch:263: trailing whitespace.
> >    generally lead to better and more accurate fixes as the LLM's reasoning
> > /home/user/Projects/linux/.git/rebase-apply/patch:282: trailing whitespace.
> > - Within two weeks, a representative of this group will communicate the
> > warning: 4 lines add whitespace errors.
> > 
> > Should we handle with whitespace?
> 
> No, the trailing whitespace should be fixed (i.e., deleted)
> and then resend the patches.

Right, I was actually trying to gently point out that the trailing
whitespace should be fixed. ;-)

This should be caught easily by checkpatch.pl, or simply by running
b4 prep --check, I guess. Better run it before sending out next time.

Thanks.

On Thu, Sep 03, 2026 at 08:29:33PM +0800, Weijie Yuan wrote:
> Thanks for Cc'ing me.
> 
> On Wed, Sep 02, 2026 at 03:43:58PM +0700, Nguyen Duc Thinh wrote:
> > This patch series performs a thorough pass across several files 
> > in the Linux kernel process documentation directory. The primary focus
> > is to improve readability and maintain a professional tone throughout 
> > the guides for a global developer audience.
> > 
> > Core changes include:
> > - Expanding conversational contractions (e.g., "don't" to "do not").
> 
> Is this necessary? I'm not sure.

It seems a bit pointless to me. Contractions will creep back in as
patches are merged. We would need e documentation editor in charge of
ensuring a consistent style, and I think the documentation maintainers
have far better things to do.

> > - Rectifying minor punctuation oversights and grammatical typos.
> > - Standardizing terminology formatting to elevate professional voice.
> > 
> > Extra notes:
> > - I originally intended to send a 12-patch series to cover the whole
> >   directory, but decided to scale it back to these 5 high-quality
> >   patches to ensure thorough accuracy and a manageable review cycle.
> >   
> >   Also I want to know the current progress of the patch titled 
> >   "Capitalize Git, Quilt, and Mercurial consistently".
> 
> It has been applied:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/docs/linux.git/commit/?id=4a0be1a25d98672391e8ad2a0802f08609397274
> 
> > v2:
> >   - Resending the complete 5-patch series together as a single cohesive 
> >     thread. (Apologies, the v1 submission suffered a terminal wildcard 
> >     argument error that accidentally truncated the transmission 
> >     after 1/5).
> 
> A better practice is to name it [PATCH v1 RESEND], I guess?
> 
> > Nguyen Duc Thinh (5):
> >   Documentation: process: Clean up grammar, tone, and contractions in
> >     core files
> >   Documentation: process: Clean up grammar and tone in next guide files
> >   Documentation: process: Refine language, tone, and grammar in
> >     subsequent files
> >   Documentation: process: Refine language, tone, and grammar in
> >     subsequent files
> >   Documentation: process: Clean up grammar and tone across multiple
> >     files
> 
> Output of 'b4 shazam':
> 
> ...
> Applying: Documentation: process: Clean up grammar, tone, and contractions in core files
> Applying: Documentation: process: Clean up grammar and tone in next guide files
> Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> Applying: Documentation: process: Clean up grammar and tone across multiple files
> /home/user/Projects/linux/.git/rebase-apply/patch:72: trailing whitespace.
>   License (about which more will be said below).  The author is not a
> warning: 1 line adds whitespace errors.
> /home/user/Projects/linux/.git/rebase-apply/patch:244: trailing whitespace.
> Which is nice, since there is no more insanity in the form of fake-generic
> warning: 1 line adds whitespace errors.
> /home/user/Projects/linux/.git/rebase-apply/patch:261: trailing whitespace.
>    rare cases, an AI assistant capable of finding a bug is capable of fixing it.
> /home/user/Projects/linux/.git/rebase-apply/patch:262: trailing whitespace.
>    Fixes written within the same session used to identify the bug will
> /home/user/Projects/linux/.git/rebase-apply/patch:263: trailing whitespace.
>    generally lead to better and more accurate fixes as the LLM's reasoning
> /home/user/Projects/linux/.git/rebase-apply/patch:282: trailing whitespace.
> - Within two weeks, a representative of this group will communicate the
> warning: 4 lines add whitespace errors.
> 
> Should we handle with whitespace?

-- 
Regards,

Laurent Pinchart

On Thu, Sep 03, 2026 at 03:54:54PM +0300, Laurent Pinchart wrote:
> > On Wed, Sep 02, 2026 at 03:43:58PM +0700, Nguyen Duc Thinh wrote:
> > > This patch series performs a thorough pass across several files 
> > > in the Linux kernel process documentation directory. The primary focus
> > > is to improve readability and maintain a professional tone throughout 
> > > the guides for a global developer audience.
> > > 
> > > Core changes include:
> > > - Expanding conversational contractions (e.g., "don't" to "do not").
> > 
> > Is this necessary? I'm not sure.
> 
> It seems a bit pointless to me. Contractions will creep back in as
> patches are merged. We would need e documentation editor in charge of
> ensuring a consistent style, and I think the documentation maintainers
> have far better things to do.

Agreed. I think contractions are fine as they are. (?) And I do not see
a need to expand them.

> > > - Rectifying minor punctuation oversights and grammatical typos.
> > > - Standardizing terminology formatting to elevate professional voice.

For these two points, it's a little bit painful to find other types of
modifications among numerous "which/that". ;-)

Thanks.

Weijie Yuan <wy@wyuan.org> writes:

> On Thu, Sep 03, 2026 at 03:54:54PM +0300, Laurent Pinchart wrote:
>> > On Wed, Sep 02, 2026 at 03:43:58PM +0700, Nguyen Duc Thinh wrote:
>> > > This patch series performs a thorough pass across several files 
>> > > in the Linux kernel process documentation directory. The primary focus
>> > > is to improve readability and maintain a professional tone throughout 
>> > > the guides for a global developer audience.
>> > > 
>> > > Core changes include:
>> > > - Expanding conversational contractions (e.g., "don't" to "do not").
>> > 
>> > Is this necessary? I'm not sure.
>> 
>> It seems a bit pointless to me. Contractions will creep back in as
>> patches are merged. We would need e documentation editor in charge of
>> ensuring a consistent style, and I think the documentation maintainers
>> have far better things to do.
>
> Agreed. I think contractions are fine as they are. (?) And I do not see
> a need to expand them.
>
>> > > - Rectifying minor punctuation oversights and grammatical typos.
>> > > - Standardizing terminology formatting to elevate professional voice.
>
> For these two points, it's a little bit painful to find other types of
> modifications among numerous "which/that". ;-)

I have to agree with all of that; I don't see merging this series as it
is now.  We have so many documentation problems, and this sort of churn
just does not address any of them.

Thanks,

jon