| | 1 | [[TOC]] |
| | 2 | = Ticket Submission guide = |
| | 3 | |
| | 4 | == Introduction == |
| | 5 | |
| | 6 | Reporting a bug, requesting a feature or posting a patch is more than just submitting a ticket. Any successful ticket basically involves three steps: |
| | 7 | |
| | 8 | 1. '''Gathering information''' |
| | 9 | |
| | 10 | Before you submit a ticket, you search the database to see if similar tickets have been submitted before. Also, you search all the required background information needed so that your ticket can be handled efficiently |
| | 11 | |
| | 12 | 2. '''Submitting the ticket''' |
| | 13 | |
| | 14 | Be verbose in your ticket description. It is hard to provide too much information, but very easy to leave out vital information. |
| | 15 | |
| | 16 | 3. '''Wait for a solution and provide further feedback if needed''' |
| | 17 | |
| | 18 | Fixing bugs or implementing features can take a lot of time. While we, the developers, do read all tickets, we do not have the time to reply to every ticket instantly, nor can we fix problems instantly. But eventually your ticket will get handled. |
| | 19 | |
| | 20 | You need to be patient. Don't rush, posting ''BUMP'' and the likes will not help, it will only cause further delay. |
| | 21 | |
| | 22 | Often, a developer working on your ticket will require further information. Be ready to adequately answer the developer's questions and provide the requested information. |
| | 23 | |
| | 24 | Please read on for more details on each of these steps. |
| | 25 | |
| | 26 | == What are tickets? == |
| | 27 | |
| | 28 | This site is running '''Trac''', which is an '''issue tracking system''' and every '''ticket''' is an '''issue'''. Think of a ticket as a number, under which an issue and all corresponding data gets filed under. |
| | 29 | |
| | 30 | There are three types of tickets or issues: |
| | 31 | |
| | 32 | * '''Bug reports''' |
| | 33 | |
| | 34 | Bugs can be best described as unintended behavior. |
| | 35 | |
| | 36 | * '''Feature requests''' |
| | 37 | |
| | 38 | If you would like to see certain functionality in FileZilla, then your ticket would be a feature request. |
| | 39 | |
| | 40 | * '''Patches''' |
| | 41 | |
| | 42 | Patches implement a new feature or fix bugs. |
| | 43 | |
| | 44 | The distinction between a bug report and a feature request is not always clear, but you can follow this simple rule of thumb to come to a decision between the two: Assume you want FileZilla to perform a certain task, but cannot do it. |
| | 45 | |
| | 46 | If there is no indication that this is possible with FileZilla, then it is a feature request. This still applies even if other programs can do it, but not FileZilla. |
| | 47 | |
| | 48 | If there is an indication that the task you want to perform is possible with FileZilla, e.g. a button or menu item, but the action does not work or does something unexpected, then it is a bug. |
| | 49 | |
| | 50 | === Components === |
| | 51 | |
| | 52 | Each ticket describes an issue affecting a component. The components available here are: |
| | 53 | * '''FileZilla Client''' |
| | 54 | * '''FileZilla Server''' |
| | 55 | * '''Other''' |
| | 56 | |
| | 57 | Make sure to request the correct component, or your ticket will be closed as invalid. |
| | 58 | |
| | 59 | === Ticket status === |
| | 60 | |
| | 61 | Over its lifetime, a ticket's status can change. Initially your ticket will have the '''new''' status and eventually it will reach the '''closed''' status. Other states include '''assigned''', '''accepted''', '''reopened''' or '''moreinfo'''. The latter tells you that the ticket is missing more information from you, while you as user can treat the other states just like '''new'''. |
| | 62 | |
| | 63 | == Information gathering == |
| | 64 | |
| | 65 | === Searching for existing tickets === |
| | 66 | |
| | 67 | == Submitting a ticket == |
| | 68 | |
| | 69 | == <meaningful heading here> == |
