• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7700 for generic doc work for TWiki-6.0.2. Use View topic Item7703 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

TWiki Bug Tracking System

This is the bug tracking database of TWiki. Please report new defects if you find any.

How to use the Bugs Web

The Bugs web is intended for tracking live work in progress. It is intended for reporting issues, and then tracking progress towards getting those issues fixed. Issues are simply structured TWiki topics, where forms are used to store a number of fields that contain data about the issue.

Searching the database

There are three options:

  • DetailedItemsQuery - use this to query the database by any field you like.
  • AllOutStandingItems - perform general purpose searches over the database.
  • Each extension also has its own search topic, to simplify tracking for extension authors.

You can also use the standard TWiki search support for searching the content of the database for related issues etc.

Submitting a new Report

First search thoroughly here and in the TWiki Support web to make sure the issue hasn't already been reported. Click on the New topic Create New Report menu item located in the Bugs web menu on top.

Requesting new features

The TWiki bug tracking system is not used to request new features.

To raise a proposal for a new feature go to the TWiki Feature Proposals TWiki application in the TWiki Codev web. Here you will find already submitted proposal. You will find the links to the process we follow.

The bug tracker does contain a classification for enhancements. It is used for

  • Tracking the implementation of already agreed feature proposals
  • Tracking very minor "no brainer" enhancements
  • Tracking items raised as bugs but the developers found the item to be an enhancement.

Describing the issue

The Summary field and the topic body should be used to report the issue, and then for each state change, the topic body should document the reason for the change.

The topic body is free-form; you can type what you like here. Good practice is to sign your input (so people can get back to you) and to separate inputs with a HR (--- on a line of it's own). It is very important to provide sufficient information to allow the problem to be reproduced on someone else's system. Make sure you fill in the Codebase field to indicate what versions you have detected the problem in.

Please watch for changes in your reports. You may be asked for further information. You can add yourself to WebNotify, with a list of your interesting bug numbers, and you will be mailed with changes.

Bugs web should not be used for abstract discussion (e.g. design). It is intended for documenting and tracking specifics. It can sometimes be tricky to distinguish between the two, but the general rule of thumb is to add a report to this web when you

  1. Detect a reproducible bug or
  2. Know the specific steps required to make an enhancement Less specific discussion should be conducted on TWiki:Codev/WebHome

What is the issue relevant to?

Each issue has an Applies To field that indicates what part of TWiki the issue is relevant to. This can be:
  • Engine - the core TWiki code and documentation, not including the Standard Release Components
    • You can optionally use the Component field to narrow it down to e.g. BuildScripts etc
  • Extension - plugins, skins, contribs, twiki applications - any sources or documentation in the twikiplugins area, including those extensions shipped with the default package.
    • The name of the affected component should be put in the Component field. Note that all extensions should have a topic in the Bugs web, that contains one line: %INCLUDE{Component}%. This will list all the issues against that extension.

How important is it?

Priority is used to flag the perceived importance of an issue.
  • Enhancement means the issue describes an improvement to existing functionality, or new functionality
  • Low means the issue is non-critical, and is really more of an annoyance than anything else
  • Normal means that this is probably a bug, but can be lived with
  • Urgent means it really is a bug, and can't be lived with. An open Urgent will normally block a release
Anyone can change a priority, but they must explain the change in the body of the report.

Open Requirement or Urgent bugs against the Engine, or against any of the Standard Release Components, will block a TWiki release.

What's happening with my report?

Issues have a State, which is a step in a generic, loose lifecycle (the lifecycle has no constraints on the transitions between states).
  • New - the issue has just been found, and hasn't been analysed yet, or there is new data about an existing issue.
  • Waiting for Feedback - the report was insufficient to analyse the issue, and more feedback is needed from the reporter. The person expected to provide that feedback will be listed in the Waiting For field
    • Once that person has added feedback they should flip the state back to New
    • If they fail to provide feedback within 30 days, the issue will probably be discarded
  • Confirmed - the issue has been analysed, and the priority has been confirmed (or changed) by a developer. The item can henceforth be classified regarding release blocking status etc. Issues in this state are waiting for someone (anyone) to address them.
  • Being Worked On - the issue has been picked up by someone who is trying to address it. Their name will be (must be) listed in the Waiting For field for the issue to remain in this state. The main purpose of this field is to stop two people simultaneously trying to fix the same issue.
  • Waiting for Release - the issue has been addressed, and the change is pending inclusion in a release. The type of release it is targeted for (patch, minor or major) is shown in the TargetRelease field. The release manager will use this field to track what is ready for release, and will flip the state to Closed and mark the Released In field when the release is actually made.
  • Closed - the issue has been fixed to the satisfaction of the fixer, and has been released.
  • No Action Required - the issue was already fixed, or it's a duplicate, or an RTFM. The text will explain why. Anyone can change a state, but they must explain the change in the body of the issue.

You can see the state of any reports you submit by clicking on the "My Reports" button in the left bar.

Follow up

For a major part of the bug reports the developers runs into trouble reproducing the problem and the developer will ask for specific information. Please revisit your bug report daily and follow up with the requested information quickly. If a reporter does not respond within a fair amount of time the bug report gets closed unresolved.

How can you help?

  • First and foremost, remember that TWiki is an open source project. Nobody gets paid to work on it, they are all donating their free time because they enjoy doing so. So be polite, and do your best to describe the issue as fully and accurately as you can. It is critically important that you describe clearly how to reproduce a problem, or you may end up simply wasting someone else's precious free time.
  • Monitor your reports, and respond quickly if you are asked for feedback.
  • If you have any programming skills, then you are encouraged to try and fix the issue yourself, and post a patch with your report.
  • You don't need programming skills for documentation fixes, so you really have no excuse for not posting the detailed fix with the report.
  • If you need a quick fix, then you can always throw some money at the problem and use a TWiki consultant to do the work for you.

About this bug tracking database

This is an Item Tracking System implemented using TWikiForms. It has been implemented to be used in a web on its own, but could be intermingled with a discussion style TWikiWeb. This web runs on the latest bleeding edge code, automatically refreshed from the TWiki subversion repository every 10 minutes. It is a pure TWiki Application implemented using only topics, and what you get in the box when you download TWiki. You can download a subset of it for your own use from TWiki:Plugins/BugsContrib.

Edit | Attach | Watch | Print version | History: r38 < r37 < r36 < r35 < r34 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r38 - 2017-08-07 - PeterThoeny
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback