Re: [PATCH v2 0/5] Documentation: process: Clean up grammar, tone,

[Laurent Pinchart]

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