The guidelines

Good reports have more chances to be fixed than bad ones. We understand that you are not a professional software developer or quality control engineer. We will consider implementing automated bug report tools. But still there are some techniques of writing a good report by hands:

• Summary of your report should be brief but as precise as possible. It should summarize the problem in few words and provide as much information as possible. For instance, sumary Bugs is bad because we understand that bug report usually is about bugs, not about money donations. Summary Problem with version 2.0 is usually also bad because we know that people use the last version of product (and moreover, there is a special field in a bug report form which indicates the version where problem was found) Summary Chart is not repainted on closing task properties dialog is perfect.
• Description should provide more or less exact scenario of reproducing your problem, especially if reproducing is not straightforward. It should also describe an expected and actual results. A good description looks similar to the following:
  1. Create 5 new tasks: task1, task2,..., task5
  2. Indent task2 and task 3 into task1 and indent task5 into task4
  3. Draw a dependency from task2 to task5 using mouse
  Expected: dependency takes effect and task5 immediatly shifts to the right, together with it's supertask task4. Actually: task5 gets shifted only when I save and reopen project

• Additional information is very useful. First of all, we are interested in console output. If you run GanttProject using some menu or desktop shortcut, please do try to start it from console window (double click ganttproject.bat on Windows systems or ganttproject.command on MacOSX) and paste the console output to the bugreport. Operating system, JRE version, your locale and look'n'feel (aka 'appearance') may also be important, please specify them.

Now, you may proceed to GanttProject bug tracker