Do you code?
Full Tutorial on how to submit a bug report - 14min
If your problem may be a general problem of understanding check the check the Tiki Documentation.
Before adding a tracker item please check if someone has reported the same issue. If so, please use the ratings and vote to express your support. You can also comment the tracker item with more information. You can check keywords to filter the items to a shorter list. You can also try out the dynamic filter.
If possible, please try to duplicate the bug on a clean install to make sure it’s not a local configuration problem. You will be able to create a show.tiki.org (show.t.o) instance associated with your wish right after you save your wish details (see below for more details). Alternatively, you could use demo.tiki.org, where you can also be logged in as admin, but keep in mind that data there is refreshed periodically, and it’s not easy for developers to get a snapshot of the database to reproduce and debug the issue localy in their own computers, nor to you to update the instance to test the issue again with the latest code after they submit a fix for it.
If a bug is really old, it doesn’t mean that no one cares. It could just be that no one else has that bug, suggesting user error or a very special/rare configuration. So, once you are sure it’s a real issue:
Add one item (bug, feature request, or others) per entry (unless they are very closely related); be as precise and pragmatic as possible. Assign to 1 or more categories as appropriate. Please do not put a high priority for no good reason. Please describe in easy terms for others to be able to reproduce the issue.
If others have questions about it, please answer promptly so things can progress.
You can also report a theme/CSS issue when a bug affects just a theme but not Tiki code in general.
You need to login to submit an item on the wishlist.
You may also want to read: How to Report Bugs Effectively by Simon Tatham.
Below are list of fields to fill in
The rating is the result of votes by you and other users. It is OK to vote for your own submission.
Please be descriptive. It is ok to start with the same of the feature. Ex.: Forum: problem with xyz
Be reasonable. Not everything can be top priority.
For a bug:
- How bad is the bug?
- How easy to fix?
- Will data be lost?
- Do you get and ugly/bad error message (from mysql or PHP)
- Is there a workaround?
- Is this a widely-used feature or configuration (vs a sub-feature)?
- Does it prevent you from using the feature? (vs an annoyance)
- Is is a new bug? (regressions are a higher pririoty because they are a disincentive to upgrading)
For a feature request (new feature or enhancement to an existing feature)
- Will this be a popular feature which will attract lots of people to Tiki?
- Is it easy to do?
- Will it fit in well with the rest of the application? (some stuff just deserves to be there!)
If you assign too high, an admin will change your score and move it even lower!
Check all that apply. This is used to filter items in the Keywords list, available on the right hand side. You can put your mouse over each word and have a bit more description what this feature is about. For more information about features, please see doc:features
We have one tracker for everything. Sometimes, a bug is also a feature request.
- The feature is coded but it doesn’t work. (obvious error message)
- Bug (Conflict of two features)
- Feature A works. Feature B works. But when you try both together, something goes wrong.
- Bug (Regression)
- Newly introduced bug during stabilization period (ex.: 1.9.7 -> 1.9.8). Sometimes, a bug (or security) fix introduces another bug. Also, minor feature enhancements happen even in stabilization mode. They are not supposed to cause issues (risky ones are done in development branch). But sometimes, some things slip through. These are high priority because people won’t want to upgrade (vs a bug which has always been there).
- Bug (Consistency)
- As an all-in-one application, we come to expect that all parts of the system behave the same. These are often also usability issues (see below)
- Bug (Usability)
- the feature is coded but the way it’s done, users are not able to accomplish their goals (ex.: interface too complex)
- Community Projects
- Something non-code related but should be taken care of. To get a feel of what belongs here, please check this page: Community Projects
- Documentation (or Advocacy)
- Will appear here: Documentation
- Feature request
- A new feature or an enhancement to an existing feature
- If you are suggesting a fix to the code. You can also apply for SVN access to commit your fix directly.
- Support request
- Means you need help. Not necessarily a bug but you can’t get the thing to work. Forums are better for this.
Check all that apply.
A *.tiki.org site -> See DogFood
Describe the problem as best you can. If you are not using Linux and MySQL, please mention it as it could be related to less-used configurations.
To help developers solve the bug, we kindly request that you demonstrate your bug on a show.tiki.org instance. To start, once you have added your wish, click to see it and simply select a version and click on “Create show.tiki.org instance” in the provided fields below in that page.
Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is “admin”) and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show.tiki.org.
See the tutorial above for more information.
If the bug or feature relates specifically with one of the on-going projects in the list, tick the appropriate box. (optional)