GitHub: Add contributor guidelines

.gitattributes

@@ -2,3 +2,4 @@
 /appveyor.yml export-ignore
 /ci export-ignore
 /.gitattributes export-ignore
+/.github export-ignore

.github/CONTRIBUTING.md

@@ -0,0 +1,95 @@
+Contributing to libjpeg-turbo
+=============================
+
+libjpeg-turbo is a stable and mature product with a worldwide reach, it is an
+ISO/ITU-T reference implementation of the JPEG standard, and its maintainer
+does not earn a salary for maintaining it.  As such, not every code
+contribution can or will be accepted into the libjpeg-turbo code base.  In
+order to maximize the chances that a code contribution is acceptable, please
+adhere to the following guidelines:
+
+1. If the code contribution is a bug fix, then please ensure that enough
+information is provided so that the maintainer can readily reproduce and
+document the bug.  That information should include:
+    - A clear and concise description of the bug
+    - The steps and (if applicable) images necessary to reproduce the bug
+    - The compilers, operating systems, and CPUs with which the bug was
+      observed
+    - The versions of libjpeg-turbo with which the bug was observed
+    - If the bug is a regression, the specific commit that introduced the bug
+      (use `git bisect` to determine this)
+
+2. If the code contribution will implement a major new feature, then please
+contact the project maintainer (through a
+[GitHub issue](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/new),
+[direct e-mail](https://libjpeg-turbo.org/About/Contact), or the
+[libjpeg-turbo-devel mailing list](https://libjpeg-turbo.org/About/MailingLists))
+prior to implementing the feature.  In general, major new features that are
+potentially disruptive to the quality of libjpeg-turbo are unlikely to be
+accepted unless:
+    - The new feature is within the existing scope of libjpeg-turbo.
+    - The new feature has been thoroughly regression tested and benchmarked on
+      all of the supported platforms that are potentially affected by it.
+    - The new feature has been documented clearly and concisely in the change
+      log and (if applicable) the libjpeg and TurboJPEG API documentation and
+      man pages.
+    - The code implementing the new feature is formatted consistently with the
+      rest of the libjpeg-turbo code base (use
+      [checkstyle](https://github.com/libjpeg-turbo/checkstyle) to validate
+      this.)
+    - The new feature does not introduce new members into the exposed libjpeg
+      API structures (doing so would break backward ABI compatibility.)
+    - The new feature does not alter existing libjpeg-turbo usage or
+      development workflows.
+    - The code implementing the new feature is elegant, easily maintainable,
+      and causes the least possible amount of disruption to the libjpeg-turbo
+      code base.
+    - The new feature is based on the dev branch of the libjpeg-turbo
+      repository.
+
+    ... OR ...
+
+    - Your organization is prepared to pay for the labor necessary to ensure
+      all of the above.  Even the most well-written patches can still require
+      a significant amount of labor to clean up, test, and integrate.  (See
+      above RE: the maintainer not earning a salary.)
+
+    Specific types of features that *will not* be accepted:
+
+    - Features that extend the scope of libjpeg-turbo to support image formats
+      other than DCT-based JPEG and JFIF
+    - Features that extend the scope of libjpeg-turbo to support image
+      processing algorithms that are not necessary for JPEG compression or
+      decompression
+    - Extensions to the JPEG format that have not been approved by the
+      appropriate standards bodies
+    - Non-trivial performance enhancements that have less than a 5% overall
+      impact on performance
+
+3. If the code contribution is a build system enhancement, then please be
+prepared to justify the enhancement.  In general, build system enhancements
+are unlikely to be accepted unless:
+    - The enhancement is potentially beneficial to a significant number of
+      upstream libjpeg-turbo users/developers.  (If the enhancement is only
+      beneficial to a downstream project, then it does not belong here.)
+    - The enhancement has been tested with the following CMake versions:
+          - The earliest version of CMake that libjpeg-turbo currently supports
+            (refer to CMakeLists.txt)
+          - The most recent major version of CMake
+          - (if applicable) The earliest version of CMake with which the
+            enhancement can be used
+    - The enhancement has been tested on all of the major platforms (Mac,
+      Linux, Windows/Visual C++, Windows/MinGW) that are potentially affected
+      by it.
+    - The enhancement does not introduce new build system requirements or CMake
+      variables unless absolutely necessary.
+    - The enhancement does not alter existing libjpeg-turbo development
+      workflows.
+
+    Specific types of build system enhancements that *will not* be accepted:
+
+    - Enhancements that allow libjpeg-turbo to be built from a subdirectory
+      of a downstream repository.  These enhancements are not maintainable in
+      the upstream libjpeg-turbo build system.  Use the CMake
+      `ExternalProject_Add()` function instead.
+    - Enhancements that introduce new (non-CMake-based) build systems