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
