contrib : refresh

[ggerganov]

• Clarify test-backend-ops
• Simplify PR template
• Add CODEOWNERS

[JohannesGaessler]

Should we add a checkbox about whether or not a contributor will be available long-term for maintaining their code?

[JohannesGaessler]

Suggested change

	- Run the `test-backend-ops` tool to validate different backend implementations of the `ggml` operators
	- If you modified GGML, run the `test-backend-ops` tool to check whether different backend implementations of the GGML operators produce consistent results (this requires access to at least two different GGML backends). If you modify an operator or add a new one, add the corresponding test cases.

[ggerganov]

Should we add a checkbox about whether or not a contributor will be available long-term for maintaining their code?

I think we can add a bullet to the CONTRIBUTING.md that we hope and appreciate if contributors will be available for long-term support of their changes. A checkbox might make it a bit too formal. If other collaborators agree that the checkbox would be a good idea, we will add it.

[JohannesGaessler]

A bit off-topic, but what is our preferred way to write ggml/GGML/ggml in documentation? When I updated the MNIST example I went with the way it's written in the README, which at the time was "GGML". Currently the linked "Introduction to ggml" consistently uses "ggml". (I don't really have a preference.)

[ggerganov]

I prefer to use ggml and llama.cpp - all-lowercase. I find the accent is helpful and add it to the main subjects of a comment, so either ggml or ggml is fine.

I use GGUF all-capital because this is the way it was introduced and proposed by the community.

[ngxson]

Should we add a checkbox about whether or not a contributor will be available long-term for maintaining their code?

I think we can also take advantage of codeowners file, which automatically ping someone when new PR is added in certain parts of the project

[JohannesGaessler]

I was thinking about it more in terms of negotiation. My perspective is that a large part of the work in software development lies in maintaining code after the initial implementation. I am actively looking out for issues caused by code that I myself wrote and try to provide fixes in a timely fashion (since it's difficult for me to find the time and motivation to help with other areas of maintenance such as reviewing PRs that are not related to anything I'm already doing). As such I am extremely wary when it comes to merging PRs that would increase maintenance disproportionally to the benefit they provide, in such cases I am generally only willing to merge them if they come with a promise to help with maintenance. It is much easier to secure a commitment if you make it a precondition for the thing that the other party wants (merging the PR) instead of asking for it after the fact. Though these cases are I think rare enough that I think it's also fine to just ask informally if appropriate.

[slaren]

IMO even the "I have read the contributing guidelines" checkbox is useless. You can very easily tell that many contributors never read them because they don't format the PR title in the way the guidelines ask.

Checkboxes don't mean anything. The only way you can trust that a contributor will be available to maintain their code is if they have an history of doing so.