docs: Added initial PR template with directions for doc only changes and squash merges [no ci]

[nicolasperez19]

Summary

• Solves issue Refactor: Add CONTRIBUTING.md and/or update PR template with [no ci] tips #7657

Changes Made

• Added directions to the README so that collaborators follow the PR template when sending a PR
• Added a general pull request template
  • Suggests to collaborators to add [no ci] to the commit title
  • Suggests to collaborators to format commit titles <module>:<commit title> (#<issue_number>) when squashing multiple commits on merge

Additional Information

• The general PR template is very rough, so adding changes is welcome!

[mofosyne]

Nice, I be interested to see if everyone else think it's good.

I would like to also add that I've been adding 'review complexity' manually, but it be good to get the submitter to indicate their subjective take on how hard it would be to review their PR. The idea is that at the very least it would speed up my manual assessment and labeling of PR... and also that later we can add some automation to do the PR complexity label automagically.

Did a bit of research and found this option out:

• https://github.com/Bhacaz/label-regex
  • It looks to do the job but is not an official github action

We are currently using actions/labeler for labeling PRs but it can only do it based on content and not on PR title and description.

• issue labeler by actions: https://github.com/actions/labeler
  • We are using this but its designed specifically for PR labeling based on file content and branch name, but does not have the ability to label by PR title and description
    • Chasing up this PR feat(match): matches by PR title and body actions/labeler#688 which does enable such feature

In this case however to keep this PR complexity down, don't try to add this automation in. We just need to make sure we can add a regex matching process for it in the future somehow.

Approving, but waiting for others to see if we need to flesh it out. I think it's good to keep this simple however.

[ggerganov]

It's better to add a CONTRIBUTING file in the repo and the PR template to just reference the file:

Before opening the PR make sure to read CONTRIBUTING

[nicolasperez19]

I made some modifications following everyone's advice.

• I added a field to the PR template for the review complexity level so that it's easier for @mofosyne to triage PRs.
• I moved most of the contribution guidelines to its own markdown file
• In the PR template I referenced ggml-ci and the test commands in the tests folder, and gave an example command following @ggerganov's adivce

[nicolasperez19]

I took out most of the fluff from the PR template and moved it to CONTRIBUTING

[slaren]

It would be nice if there was a brief explanation of llama-bench, compare-llama-bench.py and compare-commits.sh for PRs that affect performance. It's not very easy to find information about these tools without looking at other PRs, and many people are still using main to test performance. Basically, if the PR is meant to improve performance, it is recommended to include the results performance tests using llama-bench or its related tools.

[mofosyne]

@slaren I'm not sure @nicolasperez19 would be familiar enough about these, so you may want to add some pointers where he should read up to write about it.

I've adjusted the PR a bit to include GG's and my preferred changes. As you got some extra feedback, I'll hold back again from merging to give @nicolasperez19 a chance to respond.

[ggerganov]

It's a good first step - we'll expand after we merge it. Thanks

[mofosyne]

@nicolasperez19 now merged in. Feel free to explore slaren suggestion in a separate PR