contributing: new contributors should not submit trivial fixes

[am17an]

Overview

Additional information

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: No

[ngxson]

No strong opinion about this tbh. I do understand that we received quite a large amount of spam in this category lately, but typo & trivial fixes (like documentation corrections) are still technically valid contributions.

Probably we can make this point a bit clear: No AI-generated trivial fixes

[ngxson]

Suggested change

	- If you are a new contributor
	- Limit your open PRs to 1.
	- Do not submit trivial fixes (e.g. typos, formatting changes)
	- If you are a new contributor:
	- Limit your open PRs to 1
	- Do not submit trivial fixes (e.g. typos, formatting changes)

[ngxson]

2nd suggestion: Do not submit trivial fixes --> Do not submit trivial AI-generated fixes

[am17an]

It's hard to distinguish between AI and non AI fixes when they're so trivial. My intent was to encourage first contributors to go deeper than fix a typo somewhere.

[am17an]

Of course maintainers can merge PRs if they can think it improves documentation etc, but at least we can point to this when closing.

[pwilkin]

@ngxson true, but a lot of those fall into the category of "contribution farming", where someone just wants the "contributor" badge so they can write somewhere that they're a "contributor to llama.cpp", so I think they should still be discouraged.

[ngxson]

@pwilkin yes I'm aware of this category an indeed I personally really hate this kind of contribution farming. it's no more than cheating an exam to me.

however, looking at other projects, even bigger one like the linux kernel, they still (have to?) accept trivial typo fixes. probably this is still a valid kind of contrib among open-source projects after all.

Instances like PR 23036 or 23039 are clearly low-quality AI-generated and can be closed with the reason of "AI-generated PR description". otherwise, if a contributor really read the docs / the code, spot typos and manually create a patch, that could still be count as a valid contrib by most OS projects.

[am17an]

I picked this policy up from vLLM, which doesnt accept this kind of PR. In any case the decision is up to maintainer, not like anyone reads contributing.md anyway

[ngxson]

hmm ok fine for me then, I have no strong opinion, kinda 50/50 between being inclusive vs reduce spam. but I think it's fine to accept this point on the guideline for now

(just need to fix the editorconfig before merging)

[TimYagan]

I feel that both of your perspectives are valid in terms of triviality of some PRs.

My opinion is that while typos and formatting improvements are valid, it places a significant burden on the reviewing team, therefore these should be flagged as low priority when you folks are triaging the PRs.

Ideally I would suggest that you open a "feature branch" that aims to tackle these lower priority contributions and assign non-critical contributors to review those PRs on the feature branch.

This will reduce the effort on the core functionality.

Just my two cents based on my observations from enterprise repos.

[am17an]

can someone reapprove?