Bugfixing Team
From TYPO3Wiki
| Teams Committees | This project/information is related to the Bugfixing team |
This is the working area of the Bugfixing team. You can read more on our Bug fixing team page or contact us on bugs@typo3.org.
Bug reporting
- Go to bugs.typo3.org, log in (or create a new account) and click on Report Issue.
- Please fill in the Category, Reproducibility, Severity and Priority field as accurate as possible (that will help us a lot).
- Fill in the Summary field with a short title of the bug and the Description field with a more detailed description. The more accurate information, the more likely is the bug to be fixed!
- If this is a code bug, consider using the Advanced Report to add more details!
- Add a file (see below for more details), leave the View Status at public and click on Submit report.
Contents |
Bug management
- Make use of the available status, priority and resolution fields. If you have checked a bug report, mark it acknowledged, or feedback if the original bug poster should elaborate on the issue. If a bug is a duplicate, add the duplicate ID and resolve it.
- Only assign a bug to yourself or someone else if you know that it can and will usually be fixed in a reasonable time frame, say two weeks. Don't assign bugs to the devs for inclusion unless you don't have a patch ready.
- If you don't get to fix a bug assigned to you, just release it and revert the status to confirmed. This makes re-assigning tasks a lot easier.
- Only bugs in the current stable version will be fixed (any objections against this?), which means that you have to check if some older bug still exists in the current version. Otherwise people should just upgrade.
- Make better use of the infrastructure Mantis offers: custom filters, email notifications (so that Ingmar does not have to choose randomly)
How to submit a bugfix
If you want to submit bugfixes and/or changes to Typo3 (core or extensions) please follow these guidelines:
- Separate your stuff: too many lines of code makes it hard to locate all interesting changes
- Open a bug report for each patch
- Comment the changes
- Generally, provide diff files since the changes cannot be located otherwise (compare to other patches, look at the bugtracker for example)
- Make sure the patch is not larger than 10KB since most people will be put off after just looking at the size of your changes... :-|
- If it´s an GUI issue, add a screenshot of how it looks before and after the change
Make it easy for the developer - then it´s more likely your bugfix/change will be implemented!
Bug status
Here is a short suggestion on how we could use the different bug status on bugs.typo3.org:
New
A newly filed bug report. Normally it should be in this state only a short while, maybe when waiting to be completed... When filing a bug, you should normally also change it´s status away from New.
Feedback
A request for discussing a bug report before deciding what to do with it. Could for example be used when you have two different soultions, but would like to discuss which would be the best to use. Or when you don´t have a solution but wants suggestions for one.
Acknowledged
A bug report that has enought feedback (or don´t need any), enought information to be able to reproduce or fix and at first glance seems relevant. But the bug is not confirmed yet. This status should only be set by the people in charge of the category, but can be set by the reporter or someone that is going to really fix the bug.
Confirmed
A bug report that is acknowledged and has been reproduced/confirmed and it is decided that the bug should be fixed. It is advisable that the confirmation is made by someone other than the reporter.
Assigned
Someone is working on the problem! What is happening should regulary be noted on the bug report by the assigned person.
Resolved
The bug is resolved, but not yet released to the public. It could be in CVS (or like) waiting for a new release. Please note what has been done and was it about to happen with the bug when putting it into this state!
Closed
Set a bug report in this status when:
- a bug is fixed and the result is released to the public.
- a bug is decided not to be resolved
- when it was discovered it was not a bug
- when it is a duplicate (set Resolution to "duplicate")
When closing a bug report, please always add a comment telling people what has been done and why! This status should (could?) only be set by the original reporter or the one in charge of the category.
Registration for bugfixing
Enter your names here and your prefered file/directory names
- Franz Holzinger: class.t3lib_treeview.php, class.t3lib_browsetree.php
