= How to Submit a Ticket =

=== historical note ===
In the old SourceForge tracker we had ''Bugs'', ''Patches'' and ''Feature Requests''.
Now we have ''tickets''. If you have ever used wx SF tracker, please read [wiki:WikiStart] to learn how to use the same username.

=== introduction ===
Before creating a new ticket, '''you must login'''. __Make sure that the e-mail address in your preferences is correct.__

Obviously, you should first search if the bug or proposed enhancement is already submitted (use [/search?ticket=on search] for global search or queries to list tickets with the classname in [query:status!=closed&summary~=grid title] or [query:status!=closed&keywords~=wxGrid keyword]). If you are not sure that you encountered the same bug, open a new ticket and add mutual links to both tickets (`#1234` is automatically linked). 

If you want to express interest in a bug that is already submitted, CC yourself or add more details. Or even better, try to fix it.

=== summary ===
Like in [https://wiki.ubuntu.com/X/Reporting#head-63f6d4e3e78a5db3d861bc10bdceab01d8c9ad8d other] issue trackers you should select a meaningful title. You may assume that the `summary` will be viewed together with `type` and `component`, so you don't need to write `[wxMac]` if the component is set to `wxMac`.

=== component ===
`Component` is the most important drop-down field. 

If the ticket is related to `wxHtml*`, `wxAui*`, `wxRichText*` or `wxStyledText*` or `OpenGL`, use these names as a component, but remember to write what wxPort and OS are you using.

If you see a bug in the control that has generic implementation on your platform, select `GUI-generic`. `wxGrid` has generic implementation on all platforms. `wxFileCtrl` has native implementation only on GTK. When in doubt, look it up in a header file.

If the bug is in the `base` sub-library (see [/browser/wxWidgets/trunk/build/bakefiles/files.bkl files.bkl] to find out which files belong there), select `base`.

If the ticket is relevant to more than one port (and it's neither `base` nor `generic`), select GUI-all.

`wxPython` is for Python-specific issues and for C++ classes that are in wxPython but not in wxWidgets.

`build` is for ticket related to bakefiles, `configure.in`, `wx-config`, etc.

You can probably guess when to use other options.

=== keywords ===
Use full C++ names of relevant classes as keywords (e.g. `wxFileDialog`, not ~~`file dialog`~~ nor ~~`FileDialog`~~).

If your platform is not very popular, add it also as a keyword (e.g. Solaris, IRIX, Win9x).

Other suggested keywords are: 
  * `printing`, 
  * `dnd` (for drag'n'drop problems), 
  * `transparency` (for alpha-channel problems),
  * `thread` (for concurrency problems, if wxThread is not given),
  * `regression`.

=== version ===
Setting `version` is recommended, but `milestone` can be left to developers

=== description ===

Explain how to reproduce the problem. Check if you can see it in the samples. If not, try to make a '''minimal''' modification to one of the samples to demonstrate it and attach this modification as a patch (if the patch only demonstrates the bug, don't check the patch checkbox).

If you use wxPython and can show the program in a few lines of Python code, that's also useful. Make sure the code is '''complete''' (with imports and instantiation of `wx.PySimpleApp()`) 
and '''minimal'''.

''Minimal'' means that every line of the code is necessary.

Write what platform you are using. If you tested also other platforms or older versions, let us know.

=== patch ===
Attaching a patch that fixes the bug or implements the enhancement you propose will give a higher priority to your ticket. Please read [wiki:HowToSubmitPatches] for the details.

=== final note ===
At last, when you see that the bug you reported in the past was fixed, but the ticket is still open, we will appreciate if you close it. You can easily list [query:status!=closed&reporter=$USER&group=component all open bugs you reported].

And at any time, feel welcome to verify other bugs in the tracker.