docs/CONTRIBUTING.md - third_party/glfw - Git at Google

 # Contribution Guide

 ## Contents

 - [Asking a question](#asking-a-question)
 - [Reporting a bug](#reporting-a-bug)
     - [Reporting a compile or link bug](#reporting-a-compile-or-link-bug)
     - [Reporting a segfault or other crash bug](#reporting-a-segfault-or-other-crash-bug)
     - [Reporting a context creation bug](#reporting-a-context-creation-bug)
     - [Reporting a monitor or video mode bug](#reporting-a-monitor-or-video-mode-bug)
     - [Reporting a window, input or event bug](#reporting-a-window-input-or-event-bug)
     - [Reporting some other library bug](#reporting-some-other-library-bug)
     - [Reporting a documentation bug](#reporting-a-documentation-bug)
     - [Reporting a website bug](#reporting-a-website-bug)
 - [Requesting a feature](#requesting-a-feature)
 - [Contributing a bug fix](#contributing-a-bug-fix)
 - [Contributing a feature](#contributing-a-feature)


 ## Asking a question

 Questions about how to use GLFW should be asked either in the [support
 section](http://discourse.glfw.org/c/support) of the forum, under the [Stack
 Overflow tag](https://stackoverflow.com/questions/tagged/glfw) or [Game
 Development tag](https://gamedev.stackexchange.com/questions/tagged/glfw) on
 Stack Exchange or in the IRC channel `#glfw` on
 [Freenode](http://freenode.net/).

 Questions about the design or implementation of GLFW or about future plans
 should be asked in the [dev section](http://discourse.glfw.org/c/dev) of the
 forum or in the IRC channel.  Please don't open a GitHub issue to discuss design
 questions without first checking with a maintainer.


 ## Reporting a bug

 If GLFW is behaving unexpectedly at run-time, start by setting an [error
 callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling).
 GLFW will often tell you the cause of an error via this callback.  If it
 doesn't, that might be a separate bug.

 If GLFW is crashing or triggering asserts, make sure that all your object
 handles and other pointers are valid.

 For bugs where it makes sense, a short, self contained example is absolutely
 invaluable.  Just put it inline in the body text.  Note that if the bug is
 reproducible with one of the test programs that come with GLFW, just mention
 that instead.

 __Don't worry about adding too much information__.  Unimportant information can
 be abbreviated or removed later, but missing information can stall bug fixing,
 especially when your schedule doesn't align with that of the maintainer.

 __Please provide text as text, not as images__.  This includes code, error
 messages and any other text.  Text in images cannot be found by other users
 searching for the same problem and may have to be re-typed by maintainers when
 debugging.

 You don't need to manually indent your code or other text to quote it with
 GitHub Markdown; just surround it with triple backticks:

     ```
     Some quoted text.
     ```

 You can also add syntax highlighting by appending the common file extension:

     ```c
     int five(void)
     {
         return 5;
     }
     ```

 There are issue labels for both platforms and GPU manufacturers, so there is no
 need to mention these in the subject line.  If you do, it will be removed when
 the issue is labeled.

 If your bug is already reported, please add any new information you have, or if
 it already has everything, give it a :+1:.


 ### Reporting a compile or link bug

 __Note:__ GLFW needs many system APIs to do its job, which on some platforms
 means linking to many system libraries.  If you are using GLFW as a static
 library, that means your application needs to link to these in addition to GLFW.

 __Note:__ Check the [Compiling
 GLFW](https://www.glfw.org/docs/latest/compile.html) guide and or [Building
 applications](https://www.glfw.org/docs/latest/build.html) guide for before
 opening an issue of this kind.  Most issues are caused by a missing package or
 linker flag.

 Always include the __operating system name and version__ (e.g. `Windows
 7 64-bit` or `Ubuntu 15.10`) and the __compiler name and version__ (e.g. `Visual
 C++ 2015 Update 2`).  If you are using an official release of GLFW,
 include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
 __GLFW commit ID__ (e.g.  `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

 Please also include the __complete build log__ from your compiler and linker,
 even if it's long.  It can always be shortened later, if necessary.


 #### Quick template

 ```
 OS and version:
 Compiler version:
 Release or commit:
 Build log:
 ```


 ### Reporting a segfault or other crash bug

 Always include the __operating system name and version__ (e.g. `Windows
 7 64-bit` or `Ubuntu 15.10`).  If you are using an official release of GLFW,
 include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
 __GLFW commit ID__ (e.g.  `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

 Please also include any __error messages__ provided to your application via the
 [error
 callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling) and
 the __full call stack__ of the crash, or if the crash does not occur in debug
 mode, mention that instead.


 #### Quick template

 ```
 OS and version:
 Release or commit:
 Error messages:
 Call stack:
 ```


 ### Reporting a context creation bug

 __Note:__ Windows ships with graphics drivers that do not support OpenGL.  If
 GLFW says that your machine lacks support for OpenGL, it very likely does.
 Install drivers from the computer manufacturer or graphics card manufacturer
 ([Nvidia](https://www.geforce.com/drivers),
 [AMD](https://www.amd.com/en/support),
 [Intel](https://www-ssl.intel.com/content/www/us/en/support/detect.html)) to
 fix this.

 __Note:__ AMD only supports OpenGL ES on Windows via EGL.  See the
 [GLFW\_CONTEXT\_CREATION\_API](https://www.glfw.org/docs/latest/window_guide.html#window_hints_ctx)
 hint for how to select EGL.

 Please verify that context creation also fails with the `glfwinfo` tool before
 reporting it as a bug.  This tool is included in the GLFW source tree as
 `tests/glfwinfo.c` and is built along with the library.  It has switches for all
 GLFW context and framebuffer hints.  Run `glfwinfo -h` for a complete list.

 Always include the __operating system name and version__ (e.g. `Windows
 7 64-bit` or `Ubuntu 15.10`).  If you are using an official release of GLFW,
 include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
 __GLFW commit ID__ (e.g.  `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

 If you are running your program in a virtual machine, please mention this and
 include the __VM name and version__ (e.g. `VirtualBox 5.1`).

 Please also include the __GLFW version string__ (`3.2.0 X11 EGL clock_gettime
 /dev/js`), as described
 [here](https://www.glfw.org/docs/latest/intro.html#intro_version_string), the
 __GPU model and driver version__ (e.g. `GeForce GTX660 with 352.79`), and the
 __output of `glfwinfo`__ (with switches matching any hints you set in your
 code) when reporting this kind of bug.  If this tool doesn't run on the machine,
 mention that instead.


 #### Quick template

 ```
 OS and version:
 GPU and driver:
 Release or commit:
 Version string:
 glfwinfo output:
 ```


 ### Reporting a monitor or video mode bug

 __Note:__ On headless systems on some platforms, no monitors are reported.  This
 causes glfwGetPrimaryMonitor to return `NULL`, which not all applications are
 prepared for.

 __Note:__ Some third-party tools report more video modes than are approved of
 by the OS.  For safety and compatibility, GLFW only reports video modes the OS
 wants programs to use.  This is not a bug.

 The `monitors` tool is included in the GLFW source tree as `tests/monitors.c`
 and is built along with the library.  It lists all information GLFW provides
 about monitors it detects.

 Always include the __operating system name and version__ (e.g. `Windows
 7 64-bit` or `Ubuntu 15.10`).  If you are using an official release of GLFW,
 include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
 __GLFW commit ID__ (e.g.  `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

 If you are running your program in a virtual machine, please mention this and
 include the __VM name and version__ (e.g. `VirtualBox 5.1`).

 Please also include any __error messages__ provided to your application via the
 [error
 callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling) and
 the __output of `monitors`__ when reporting this kind of bug.  If this tool
 doesn't run on the machine, mention this instead.


 #### Quick template

 ```
 OS and version:
 Release or commit:
 Error messages:
 monitors output:
 ```


 ### Reporting a window, input or event bug

 __Note:__ The exact ordering of related window events will sometimes differ.

 __Note:__ Window moving and resizing (by the user) will block the main thread on
 some platforms.  This is not a bug.  Set a [refresh
 callback](https://www.glfw.org/docs/latest/window.html#window_refresh) if you
 want to keep the window contents updated during a move or size operation.

 The `events` tool is included in the GLFW source tree as `tests/events.c` and is
 built along with the library.  It prints all information provided to every
 callback supported by GLFW as events occur.  Each event is listed with the time
 and a unique number to make discussions about event logs easier.  The tool has
 command-line options for creating multiple windows and full screen windows.

 Always include the __operating system name and version__ (e.g. `Windows
 7 64-bit` or `Ubuntu 15.10`).  If you are using an official release of GLFW,
 include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
 __GLFW commit ID__ (e.g.  `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

 If you are running your program in a virtual machine, please mention this and
 include the __VM name and version__ (e.g. `VirtualBox 5.1`).

 Please also include any __error messages__ provided to your application via the
 [error
 callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling) and
 if relevant, the __output of `events`__ when reporting this kind of bug.  If
 this tool doesn't run on the machine, mention this instead.

 __X11:__ If possible, please include what desktop environment (e.g. GNOME,
 Unity, KDE) and/or window manager (e.g. Openbox, dwm, Window Maker) you are
 running.  If the bug is related to keyboard input, please include any input
 method (e.g. ibus, SCIM) you are using.


 #### Quick template

 ```
 OS and version:
 Release or commit:
 Error messages:
 events output:
 ```


 ### Reporting some other library bug

 Always include the __operating system name and version__ (e.g. `Windows
 7 64-bit` or `Ubuntu 15.10`).  If you are using an official release of GLFW,
 include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
 __GLFW commit ID__ (e.g.  `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

 Please also include any __error messages__ provided to your application via the
 [error
 callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling), if
 relevant.


 #### Quick template

 ```
 OS and version:
 Release or commit:
 Error messages:
 ```


 ### Reporting a documentation bug

 If you found a bug in the documentation, including this file, then it's fine to
 just link to that web page or mention that source file.  You don't need to match
 the source to the output or vice versa.


 ### Reporting a website bug

 If the bug is in the documentation (anything under `/docs/`) then please see the
 section above.  Bugs in the rest of the site are reported to the [website
 source repository](https://github.com/glfw/website/issues).


 ## Requesting a feature

 Please explain why you need the feature and how you intend to use it.  If you
 have a specific API design in mind, please add that as well.  If you have or are
 planning to write code for the feature, see the section below.

 If there already is a request for the feature you need, add your specific use
 case unless it is already mentioned.  If it is, give it a :+1:.


 ## Contributing a bug fix

 __Note:__ You must have all necessary [intellectual
 property rights](https://en.wikipedia.org/wiki/Intellectual_property) to any
 code you contribute.  If you did not write the code yourself, you must explain
 where it came from and under what license you received it.  Even code using the
 same license as GLFW may not be copied without attribution.

 __There is no preferred patch size__.  A one character fix is just as welcome as
 a thousand line one, if that is the appropriate size for the fix.

 In addition to the code, a complete bug fix includes:

 - Change log entry in `README.md`, describing the incorrect behavior
 - Credits entries for all authors of the bug fix

 Bug fixes will not be rejected because they don't include all the above parts,
 but please keep in mind that maintainer time is finite and that there are many
 other bugs and features to work on.

 If the patch fixes a bug introduced after the last release, it should not get
 a change log entry.

 If you haven't already, read the excellent article [How to Write a Git Commit
 Message](https://chris.beams.io/posts/git-commit/).


 ## Contributing a feature

 __Note:__ You must have all necessary rights to any code you contribute.  If you
 did not write the code yourself, you must explain where it came from and under
 what license.  Even code using the same license as GLFW may not be copied
 without attribution.

 __Note:__ If you haven't already implemented the feature, check first if there
 already is an open issue for it and if it's already being developed in an
 [experimental branch](https://github.com/glfw/glfw/branches/all).

 __There is no preferred patch size__.  A one character change is just as welcome
 as one adding a thousand line one, if that is the appropriate size for the
 feature.

 In addition to the code, a complete feature includes:

 - Change log entry in `README.md`, listing all new symbols
 - News page entry, briefly describing the feature
 - Guide documentation, with minimal examples, in the relevant guide
 - Reference documentation, with all applicable tags
 - Cross-references and mentions in appropriate places
 - Credits entries for all authors of the feature

 If the feature requires platform-specific code, at minimum stubs must be added
 for the new platform function to all supported and experimental platforms.

 If it adds a new callback, support for it must be added to `tests/event.c`.

 If it adds a new monitor property, support for it must be added to
 `tests/monitor.c`.

 If it adds a new OpenGL, OpenGL ES or Vulkan option or extension, support
 for it must be added to `tests/glfwinfo.c` and the behavior of the library when
 the extension is missing documented in `docs/compat.dox`.

 If you haven't already, read the excellent article [How to Write a Git Commit
 Message](https://chris.beams.io/posts/git-commit/).

 Features will not be rejected because they don't include all the above parts,
 but please keep in mind that maintainer time is finite and that there are many
 other features and bugs to work on.

 Please also keep in mind that any part of the public API that has been included
 in a release cannot be changed until the next _major_ version.  Features can be
 added and existing parts can sometimes be overloaded (in the general sense of
 doing more things, not in the C++ sense), but code written to the API of one
 minor release should both compile and run on subsequent minor releases.
	# Contribution Guide

	## Contents

	- [Asking a question](#asking-a-question)
	- [Reporting a bug](#reporting-a-bug)
	- [Reporting a compile or link bug](#reporting-a-compile-or-link-bug)
	- [Reporting a segfault or other crash bug](#reporting-a-segfault-or-other-crash-bug)
	- [Reporting a context creation bug](#reporting-a-context-creation-bug)
	- [Reporting a monitor or video mode bug](#reporting-a-monitor-or-video-mode-bug)
	- [Reporting a window, input or event bug](#reporting-a-window-input-or-event-bug)
	- [Reporting some other library bug](#reporting-some-other-library-bug)
	- [Reporting a documentation bug](#reporting-a-documentation-bug)
	- [Reporting a website bug](#reporting-a-website-bug)
	- [Requesting a feature](#requesting-a-feature)
	- [Contributing a bug fix](#contributing-a-bug-fix)
	- [Contributing a feature](#contributing-a-feature)


	## Asking a question

	Questions about how to use GLFW should be asked either in the [support
	section](http://discourse.glfw.org/c/support) of the forum, under the [Stack
	Overflow tag](https://stackoverflow.com/questions/tagged/glfw) or [Game
	Development tag](https://gamedev.stackexchange.com/questions/tagged/glfw) on
	Stack Exchange or in the IRC channel `#glfw` on
	[Freenode](http://freenode.net/).

	Questions about the design or implementation of GLFW or about future plans
	should be asked in the [dev section](http://discourse.glfw.org/c/dev) of the
	forum or in the IRC channel. Please don't open a GitHub issue to discuss design
	questions without first checking with a maintainer.


	## Reporting a bug

	If GLFW is behaving unexpectedly at run-time, start by setting an [error
	callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling).
	GLFW will often tell you the cause of an error via this callback. If it
	doesn't, that might be a separate bug.

	If GLFW is crashing or triggering asserts, make sure that all your object
	handles and other pointers are valid.

	For bugs where it makes sense, a short, self contained example is absolutely
	invaluable. Just put it inline in the body text. Note that if the bug is
	reproducible with one of the test programs that come with GLFW, just mention
	that instead.

	__Don't worry about adding too much information__. Unimportant information can
	be abbreviated or removed later, but missing information can stall bug fixing,
	especially when your schedule doesn't align with that of the maintainer.

	__Please provide text as text, not as images__. This includes code, error
	messages and any other text. Text in images cannot be found by other users
	searching for the same problem and may have to be re-typed by maintainers when
	debugging.

	You don't need to manually indent your code or other text to quote it with
	GitHub Markdown; just surround it with triple backticks:

	```
	Some quoted text.
	```

	You can also add syntax highlighting by appending the common file extension:

	```c
	int five(void)
	{
	return 5;
	}
	```

	There are issue labels for both platforms and GPU manufacturers, so there is no
	need to mention these in the subject line. If you do, it will be removed when
	the issue is labeled.

	If your bug is already reported, please add any new information you have, or if
	it already has everything, give it a :+1:.


	### Reporting a compile or link bug

	__Note:__ GLFW needs many system APIs to do its job, which on some platforms
	means linking to many system libraries. If you are using GLFW as a static
	library, that means your application needs to link to these in addition to GLFW.

	__Note:__ Check the [Compiling
	GLFW](https://www.glfw.org/docs/latest/compile.html) guide and or [Building
	applications](https://www.glfw.org/docs/latest/build.html) guide for before
	opening an issue of this kind. Most issues are caused by a missing package or
	linker flag.

	Always include the __operating system name and version__ (e.g. `Windows
	7 64-bit` or `Ubuntu 15.10`) and the __compiler name and version__ (e.g. `Visual
	C++ 2015 Update 2`). If you are using an official release of GLFW,
	include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
	__GLFW commit ID__ (e.g. `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

	Please also include the __complete build log__ from your compiler and linker,
	even if it's long. It can always be shortened later, if necessary.


	#### Quick template

	```
	OS and version:
	Compiler version:
	Release or commit:
	Build log:
	```


	### Reporting a segfault or other crash bug

	Always include the __operating system name and version__ (e.g. `Windows
	7 64-bit` or `Ubuntu 15.10`). If you are using an official release of GLFW,
	include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
	__GLFW commit ID__ (e.g. `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

	Please also include any __error messages__ provided to your application via the
	[error
	callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling) and
	the __full call stack__ of the crash, or if the crash does not occur in debug
	mode, mention that instead.


	#### Quick template

	```
	OS and version:
	Release or commit:
	Error messages:
	Call stack:
	```


	### Reporting a context creation bug

	__Note:__ Windows ships with graphics drivers that do not support OpenGL. If
	GLFW says that your machine lacks support for OpenGL, it very likely does.
	Install drivers from the computer manufacturer or graphics card manufacturer
	([Nvidia](https://www.geforce.com/drivers),
	[AMD](https://www.amd.com/en/support),
	[Intel](https://www-ssl.intel.com/content/www/us/en/support/detect.html)) to
	fix this.

	__Note:__ AMD only supports OpenGL ES on Windows via EGL. See the
	[GLFW\_CONTEXT\_CREATION\_API](https://www.glfw.org/docs/latest/window_guide.html#window_hints_ctx)
	hint for how to select EGL.

	Please verify that context creation also fails with the `glfwinfo` tool before
	reporting it as a bug. This tool is included in the GLFW source tree as
	`tests/glfwinfo.c` and is built along with the library. It has switches for all
	GLFW context and framebuffer hints. Run `glfwinfo -h` for a complete list.

	Always include the __operating system name and version__ (e.g. `Windows
	7 64-bit` or `Ubuntu 15.10`). If you are using an official release of GLFW,
	include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
	__GLFW commit ID__ (e.g. `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

	If you are running your program in a virtual machine, please mention this and
	include the __VM name and version__ (e.g. `VirtualBox 5.1`).

	Please also include the __GLFW version string__ (`3.2.0 X11 EGL clock_gettime
	/dev/js`), as described
	[here](https://www.glfw.org/docs/latest/intro.html#intro_version_string), the
	__GPU model and driver version__ (e.g. `GeForce GTX660 with 352.79`), and the
	__output of `glfwinfo`__ (with switches matching any hints you set in your
	code) when reporting this kind of bug. If this tool doesn't run on the machine,
	mention that instead.


	#### Quick template

	```
	OS and version:
	GPU and driver:
	Release or commit:
	Version string:
	glfwinfo output:
	```


	### Reporting a monitor or video mode bug

	__Note:__ On headless systems on some platforms, no monitors are reported. This
	causes glfwGetPrimaryMonitor to return `NULL`, which not all applications are
	prepared for.

	__Note:__ Some third-party tools report more video modes than are approved of
	by the OS. For safety and compatibility, GLFW only reports video modes the OS
	wants programs to use. This is not a bug.

	The `monitors` tool is included in the GLFW source tree as `tests/monitors.c`
	and is built along with the library. It lists all information GLFW provides
	about monitors it detects.

	Always include the __operating system name and version__ (e.g. `Windows
	7 64-bit` or `Ubuntu 15.10`). If you are using an official release of GLFW,
	include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
	__GLFW commit ID__ (e.g. `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

	If you are running your program in a virtual machine, please mention this and
	include the __VM name and version__ (e.g. `VirtualBox 5.1`).

	Please also include any __error messages__ provided to your application via the
	[error
	callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling) and
	the __output of `monitors`__ when reporting this kind of bug. If this tool
	doesn't run on the machine, mention this instead.


	#### Quick template

	```
	OS and version:
	Release or commit:
	Error messages:
	monitors output:
	```


	### Reporting a window, input or event bug

	__Note:__ The exact ordering of related window events will sometimes differ.

	__Note:__ Window moving and resizing (by the user) will block the main thread on
	some platforms. This is not a bug. Set a [refresh
	callback](https://www.glfw.org/docs/latest/window.html#window_refresh) if you
	want to keep the window contents updated during a move or size operation.

	The `events` tool is included in the GLFW source tree as `tests/events.c` and is
	built along with the library. It prints all information provided to every
	callback supported by GLFW as events occur. Each event is listed with the time
	and a unique number to make discussions about event logs easier. The tool has
	command-line options for creating multiple windows and full screen windows.

	Always include the __operating system name and version__ (e.g. `Windows
	7 64-bit` or `Ubuntu 15.10`). If you are using an official release of GLFW,
	include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
	__GLFW commit ID__ (e.g. `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

	If you are running your program in a virtual machine, please mention this and
	include the __VM name and version__ (e.g. `VirtualBox 5.1`).

	Please also include any __error messages__ provided to your application via the
	[error
	callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling) and
	if relevant, the __output of `events`__ when reporting this kind of bug. If
	this tool doesn't run on the machine, mention this instead.

	__X11:__ If possible, please include what desktop environment (e.g. GNOME,
	Unity, KDE) and/or window manager (e.g. Openbox, dwm, Window Maker) you are
	running. If the bug is related to keyboard input, please include any input
	method (e.g. ibus, SCIM) you are using.


	#### Quick template

	```
	OS and version:
	Release or commit:
	Error messages:
	events output:
	```


	### Reporting some other library bug

	Always include the __operating system name and version__ (e.g. `Windows
	7 64-bit` or `Ubuntu 15.10`). If you are using an official release of GLFW,
	include the __GLFW release version__ (e.g. `3.1.2`), otherwise include the
	__GLFW commit ID__ (e.g. `3795d78b14ef06008889cc422a1fb8d642597751`) from Git.

	Please also include any __error messages__ provided to your application via the
	[error
	callback](https://www.glfw.org/docs/latest/intro_guide.html#error_handling), if
	relevant.


	#### Quick template

	```
	OS and version:
	Release or commit:
	Error messages:
	```


	### Reporting a documentation bug

	If you found a bug in the documentation, including this file, then it's fine to
	just link to that web page or mention that source file. You don't need to match
	the source to the output or vice versa.


	### Reporting a website bug

	If the bug is in the documentation (anything under `/docs/`) then please see the
	section above. Bugs in the rest of the site are reported to the [website
	source repository](https://github.com/glfw/website/issues).


	## Requesting a feature

	Please explain why you need the feature and how you intend to use it. If you
	have a specific API design in mind, please add that as well. If you have or are
	planning to write code for the feature, see the section below.

	If there already is a request for the feature you need, add your specific use
	case unless it is already mentioned. If it is, give it a :+1:.


	## Contributing a bug fix

	__Note:__ You must have all necessary [intellectual
	property rights](https://en.wikipedia.org/wiki/Intellectual_property) to any
	code you contribute. If you did not write the code yourself, you must explain
	where it came from and under what license you received it. Even code using the
	same license as GLFW may not be copied without attribution.

	__There is no preferred patch size__. A one character fix is just as welcome as
	a thousand line one, if that is the appropriate size for the fix.

	In addition to the code, a complete bug fix includes:

	- Change log entry in `README.md`, describing the incorrect behavior
	- Credits entries for all authors of the bug fix

	Bug fixes will not be rejected because they don't include all the above parts,
	but please keep in mind that maintainer time is finite and that there are many
	other bugs and features to work on.

	If the patch fixes a bug introduced after the last release, it should not get
	a change log entry.

	If you haven't already, read the excellent article [How to Write a Git Commit
	Message](https://chris.beams.io/posts/git-commit/).


	## Contributing a feature

	__Note:__ You must have all necessary rights to any code you contribute. If you
	did not write the code yourself, you must explain where it came from and under
	what license. Even code using the same license as GLFW may not be copied
	without attribution.

	__Note:__ If you haven't already implemented the feature, check first if there
	already is an open issue for it and if it's already being developed in an
	[experimental branch](https://github.com/glfw/glfw/branches/all).

	__There is no preferred patch size__. A one character change is just as welcome
	as one adding a thousand line one, if that is the appropriate size for the
	feature.

	In addition to the code, a complete feature includes:

	- Change log entry in `README.md`, listing all new symbols
	- News page entry, briefly describing the feature
	- Guide documentation, with minimal examples, in the relevant guide
	- Reference documentation, with all applicable tags
	- Cross-references and mentions in appropriate places
	- Credits entries for all authors of the feature

	If the feature requires platform-specific code, at minimum stubs must be added
	for the new platform function to all supported and experimental platforms.

	If it adds a new callback, support for it must be added to `tests/event.c`.

	If it adds a new monitor property, support for it must be added to
	`tests/monitor.c`.

	If it adds a new OpenGL, OpenGL ES or Vulkan option or extension, support
	for it must be added to `tests/glfwinfo.c` and the behavior of the library when
	the extension is missing documented in `docs/compat.dox`.

	If you haven't already, read the excellent article [How to Write a Git Commit
	Message](https://chris.beams.io/posts/git-commit/).

	Features will not be rejected because they don't include all the above parts,
	but please keep in mind that maintainer time is finite and that there are many
	other features and bugs to work on.

	Please also keep in mind that any part of the public API that has been included
	in a release cannot be changed until the next _major_ version. Features can be
	added and existing parts can sometimes be overloaded (in the general sense of
	doing more things, not in the C++ sense), but code written to the API of one
	minor release should both compile and run on subsequent minor releases.