ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Lee Jones <lee@kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
	Kees Cook <kees@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Miguel Ojeda <ojeda@kernel.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	SeongJae Park <sj@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Simon Glass <simon.glass@canonical.com>,
	NeilBrown <neilb@ownmail.net>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Theodore Ts'o <tytso@mit.edu>, Sasha Levin <sashal@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Vlastimil Babka <vbabka@suse.cz>,
	workflows@vger.kernel.org, ksummit@lists.linux.dev
Subject: Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
Date: Tue, 13 Jan 2026 10:05:17 -0800	[thread overview]
Message-ID: <921e154d-7e54-40ff-ae85-97b6cee7f8b2@intel.com> (raw)
In-Reply-To: <20260113103609.GA1902656@google.com>

On 1/13/26 02:36, Lee Jones wrote:
...
>> +Even if your tool use is out of scope, you should still always consider
>> +if it would help reviewing your contribution if the reviewer knows
>> +about the tool that you used.
> 
> Parsing ... okay, that took a few goes.  How about:
> 
>   Even if disclosure of your tool isn't mandated, providing this context
>   often helps reviewers evaluate your contribution more effectively.
>   Clear documentation of your workflow ensures a faster review with less
>   contention.
I agree that the sentence is hard to parse. But, I want to explicitly
say "out of scope" to tie this in to the rest of the section. How about
this?

	Even if your tool use is out of scope, consider disclosing how
	you used the tool. Clear documentation of your workflow often
	helps reviewers do their jobs more efficiently.

BTW, I do think we're well into diminishing returns territory. I'll roll
this into a v6 if there's a v6. But, if it's pulled in as-is, I think
the original can stay without causing too much harm.

...>> +Some examples:
>> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
>> + - Coccinelle scripts
>> + - A chatbot generated a new function in your patch to sort list entries.
>> + - A .c file in the patch was originally generated by a coding
>> +   assistant but cleaned up by hand.
>> + - The changelog was generated by handing the patch to a generative AI
>> +   tool and asking it to write the changelog.
>> + - The changelog was translated from another language.
> 
> Nit: Suggest removing the sporadic use of full-stops (periods) across all lists.
> 
> Or add them everywhere - so long as it's consistent.

The rule that I read is that when the bullets are full, complete
sentences, you should use periods. When they are just nouns or shards of
sentences, leave off the periods.

I _think_ that's the consensus for how to punctuate bulleted list items.

But I don't remember where I read that, if it was in Documentation/
somewhere or it was some random rule on the Internet I decided to apply.

  reply	other threads:[~2026-01-13 18:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-13  0:06 Dave Hansen
2026-01-13  5:30 ` Dan Carpenter
2026-01-13  9:28   ` Lorenzo Stoakes
2026-01-13 18:20   ` Dave Hansen
2026-01-13 18:20   ` dan.j.williams
2026-01-13 18:43     ` Sasha Levin
2026-01-13 18:50       ` dan.j.williams
2026-01-13 21:03         ` Alexei Starovoitov
2026-01-13 19:33       ` James Bottomley
2026-01-13 22:44       ` Steven Rostedt
2026-01-13  9:09 ` Lorenzo Stoakes
2026-01-13 10:36 ` Lee Jones
2026-01-13 18:05   ` Dave Hansen [this message]
2026-01-13 18:55     ` Geert Uytterhoeven
2026-01-15 15:04     ` Lee Jones
2026-01-13 19:22 ` Jonathan Corbet
2026-01-19 19:57   ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=921e154d-7e54-40ff-ae85-97b6cee7f8b2@intel.com \
    --to=dave.hansen@intel.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kees@kernel.org \
    --cc=ksummit@lists.linux.dev \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mcgrof@kernel.org \
    --cc=neilb@ownmail.net \
    --cc=ojeda@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sashal@kernel.org \
    --cc=shuah@kernel.org \
    --cc=simon.glass@canonical.com \
    --cc=sj@kernel.org \
    --cc=tytso@mit.edu \
    --cc=vbabka@suse.cz \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox