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.
