Created a simple "Pull request guidelines" section

Contributing.md

@@ -17,6 +17,11 @@ When generating the native build script for your toolset, cmake will try to find
 
 If clang format is found, then cmake will add a custom build target that can be run at any time to run clang format against *all* source files and update the formatting in them. This should be used before making a pull request so that the reviewers can spend more time reviewing the code instead of having to worry about minor style violations. On MSVC, you can run clang format by building the clang-format project in the solution. On macOS, you can either use the Makefile target `make clang-format` or by building the clang-format target in XCode. For Makefile builds, you can use the clang-format target with `make clang-format`.
 
+# Pull Request Guidelines
+Pull requests (PRs) are expected to have at least a minimal description of their intention. Pull requests with GUI changes are expected to have screenshots depicting the changes. Similarly, when fixing visual or audio issues it's nice to have sample images, video or audio.
+If there's a specific issue that's fixed by the PR, you should mention it. If you believe the issue is completely fixed by the PR, you may also [link it](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) so it's automatically closed when the PR is merged.
+
+# Code and Style Guidelines
 ### General Rules
 * A lot of code was taken from other projects (e.g. Dolphin, PPSSPP, Gekko, SkyEye). In general, when editing other people's code, follow the style of the module you're in (or better yet, fix the style if it drastically differs from our guide).
 * Line width is typically 100 characters. Please do not use 80-characters.