wiki:TicketSubmissionGuide

Version 1 (modified by Tim Kosse, 16 years ago) ( diff )

WIP

TOC

Ticket Submission guide

Introduction

Reporting a bug, requesting a feature or posting a patch is more than just submitting a ticket. Any successful ticket basically involves three steps:

  1. Gathering information

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

  1. Submitting the ticket

Be verbose in your ticket description. It is hard to provide too much information, but very easy to leave out vital information.

  1. Wait for a solution and provide further feedback if needed

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.

You need to be patient. Don't rush, posting BUMP and the likes will not help, it will only cause further delay.

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.

Please read on for more details on each of these steps.

What are tickets?

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.

There are three types of tickets or issues:

  • Bug reports

Bugs can be best described as unintended behavior.

  • Feature requests

If you would like to see certain functionality in FileZilla, then your ticket would be a feature request.

  • Patches

Patches implement a new feature or fix bugs.

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.

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.

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.

Components

Each ticket describes an issue affecting a component. The components available here are:

  • FileZilla Client
  • FileZilla Server
  • Other

Make sure to request the correct component, or your ticket will be closed as invalid.

Ticket status

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.

Information gathering

Searching for existing tickets

Submitting a ticket

<meaningful heading here>

Note: See TracWiki for help on using the wiki.