On Fri, Jun 05, 2026 at 12:12:20PM +0200, Kevin Wolf wrote: > Am 03.06.2026 um 17:35 hat Paolo Bonzini geschrieben: > > > > +**Small bug fixes** > > > > + These should be limited to 20 lines of code or less, not including > > > > + tests. You are still expected to :ref:`understand and explain your > > > > changes > > > > + <write_a_meaningful_commit_message>` and the rationale behind them. > > > > > > I think the "20 lines or less" is not going a good job at expressing > > > the intent behind this point. I'd like us to emphasize between the > > > "why" of this point, as that helps contributors & reviewers make a > > > decision of whether a change is "within the spirit" or the rule of > > > not. > > > > True but we also need a rule. The spirit is better explained elsewhere > > (and also, building consensus on spirit vs. a rule are two different > > things). > > But "20 lines or less" is still not a good rule because it measures > something that isn't really what we're after. The rule is "trivial > code", and yes, there is no good way to measure that. But that's not a > good reason to replace it with a metric as good as defining productivity > of an engineer by lines of code added. > > Can we turn this just into an example, and also be a bit more specific? > Like "20 lines of low complexity code"? (Or is it more like "moderate > complexity" that you have in mind?) But it's definitely possible to > write 20 lines that aren't trivial at all, so the rule shouldn't allow > that. > > > > Docs is an area I'm more wary of from the social expectation side rather > > > than the technical or legal side. I don't feeel like "pay attention to > > > the organization and flow" really mitigates to the tendancy to production > > > of vast reams of convincing sounding slop. > > > > Reviewers have no obligation to review. The good thing about slop is > > that saying no takes about the same effort as the author put into the > > creation of the change. > > Just saying "no, because I don't feel like reviewing this" is actually a > new thing for most of us, and doesn't feel very comfortable. We may need > to get used to it, but I don't think it's easy.
If someone repeatedly sends me slop, defined as code/text they did not read, I will warn them and eventually start ignoring them. We can mention it's something maintainers can do. > > > > +There is no requirement to include your prompts or summarize the > > > > +conversation in the commit message or cover letter, but you may do so > > > > +if you think it helps a reviewer judge the result. For example: > > > > > > IMHO we should actively discourage the inclusion of prompts > > > entirely as it is the wrong information to provide. > > > > Why? I think it helps especially in the case where we're asking for > > maintainers to apply their discretion, and for reproducibility. It may > > not be always applicable, but it can also help. > > Not sure how much reproducibility there can possibly be with LLMs. :-) > > Kevin
